Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Sun Microsystems Operating Systems Software IT

Solaris Telnet 0-day vulnerability 342

philos writes "According to SANS ISC, there's a vulnerability in Solaris 10 and 11 telnet that allows anyone to remotely connect as any account, including root, without authentication. Remote access can be gained with nothing more than a telnet client. More information and a Snort signature can be found at riosec.com. Worse, this is almost identical to a bug in AIX and Linux rlogin from way back in 1994."
This discussion has been archived. No new comments can be posted.

Solaris Telnet 0-day vulnerability

Comments Filter:
  • by nettdata ( 88196 ) on Monday February 12, 2007 @09:44AM (#17981860) Homepage
    Who the hell even THINKS about enabling telnet on any box these days?

    • Re: (Score:3, Interesting)

      by Minwee ( 522556 )
      Well, according to TFA, nobody should.
    • Re: (Score:3, Insightful)

      nothing WRONG with telnet. I use it all the time.

      but ONLY on trusted lans, of course.

      I find it quicker than ssh logins. of course its quicker, it has no encryption to do. and the initial seeding (at connect time) also takes a LONG time on some boxes (ssh to a cisco box; come back after lunch and you'll get your login prompt).

      telnet over a wan is dumb. telnet over a 10' piece of wire is NOT dumb.

      telnet has its place.
      • Re: (Score:3, Insightful)

        Telnet is dumb! Quicker than SSH? What the hell? Are you streaming video over your SSH connection or what? Most sane people just use it for a remote console, and speed isn't much of an issue in those circumstances...

        Opening/enabling telnet is a mistake. Even if you're using it safely, which, in my mind, is across a hub that isn't connected to anything else but the two computers you're talking to you've still got that port open and vulnerable. Using it on a LAN is just begging someone with a packet sniffer t
        • by Nasarius ( 593729 ) on Monday February 12, 2007 @10:01AM (#17982022)

          Quicker than SSH? What the hell? Are you streaming video over your SSH connection or what?
          I think GP is referring to the initial connect handshake. Oh no, it takes an extra 500ms to establish a secure connection. If your network is private enough to feel safe using telnet, you can certainly set up RSA/DSA keys to use SSH without a password, eliminating the time it takes to enter it.
          • Re: (Score:3, Informative)

            Well, the encryption will still add a level of overhead to your packet traffic, so the whole thing will be "slower" but, from experience, you can play Zangband in either one and you'll still have to turn the key delay way up to keep it from getting you killed, and that's about the most bandwidth intensive application I've ever run in ssh that could have been run just as well in telnet.
          • Oh no, it takes an extra 500ms to establish a secure connection

            It may take _that_ long on a sparc box, but stick some nice amd opterons in there and you'll never even notice. Seriously though, even on a private lan is stupid. SSH has replaced telnet for a reason. If that was one of my servers, I'd tell the guy to GFY.
            • Re: (Score:3, Interesting)

              by ePhil_One ( 634771 )
              It may take _that_ long on a sparc box, but stick some nice amd opterons in there and you'll never even notice.

              Thats nice and all, but I believe the GP was referring to systems w/ embedded processors, where thast not an option, and I also think he was whining about the initial key gereation (that first time you set it up process), which can take a bit of time on embedded processors. As an example, the Pix 515 has a lowly Pentium 166 at its core, the heavy math of calculating big primes can take a while.

              • by arth1 ( 260657 ) on Monday February 12, 2007 @12:08PM (#17983590) Homepage Journal
                Vendor support for ssh is one factor. Many companies have aversions to installing software unless it's backed by FULL support from the vendor. Having to go to a third party, like F-Secure, to get vendor support is often undesirable, and unfortunately, security can lose to support requirements, service level agreements and response time. Even worse is that there's multiple and sometimes incompatible versions of SSH out there - what may come with one system isn't guaranteed to work with another.
                Can you get the OS vendor to jump and have a man there within 30 minutes to fix it if a supported OS function doesn't work? Yes. Can you get the OS vendor to jump and have a man there within 30 minutes if OpenSSH doesn't work? No. Sometimes it's as simple as that, unfortunately.

                That said, don't think that I believe telnet is a good substitute for ssh, but often, and especially in a turtled environment (hard on the outside, soft on the inside) where five nines are more important than internal security, it may still be a better choice, at least until all the OS vendors provide fully supported (and compatible!) versions of SSH.
          • Re: (Score:3, Informative)

            its NOT 500ms on my cisco boxes.

            admittedly, they'd old 'test' junker boxes that I use for netmgt testing. I had to write some expect style scripts to login to them, throw a command, get the buffer output, parse it and disconnect. for each kind of 'thing' I wanted to remotely retrieve.

            it took over 20 secs, on SOME cisco boxes, to get a ssh prompt back.

            quite unacceptable.

            then I used telnet and it was almost instant.

            again, if you secure your lan (my 10' piece of PRIVATE WIRE) there is NOTHING wrong with teln
      • Re: (Score:3, Insightful)

        by walt-sjc ( 145127 )
        If ssh on your cisco boxes is slow, you either have serious network problems or your cisco box has been end-of-life for 10 years. If you don't practice security inside your network, you are asking for trouble. Perimeter-only security is Sooo 1990. Time to join the next century.
        • by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Monday February 12, 2007 @10:23AM (#17982246) Homepage Journal

          If ssh on your cisco boxes is slow, you either have serious network problems [...]

          Most likely, the reverse DNS is misconfigured. This is the number one reason for ssh-login delays. Maybe, the nameservers initially put into the router's configuration are no longer reachable due to subsequent "hardening". Or, maybe, they went away and were replaced long ago — without anybody telling the routers. Nothing else on a router uses DNS usually, so this problem affects only ssh-daemon and gets blamed on it...

          The daemon could, of course, be a little bit smarter and not try to do a reverse DNS, when there are no hostname-based authorization rules in the first place... But that's a minor bug compared to reverse DNS being dysfunctional.

          • That's exactly what I meant by "serious network problems". Reverse DNS being broken seems to be the number one cause of slow SSH. If reverse DNS is missing / broken, ssh won't be the only thing slow.

      • by alexhs ( 877055 )
        What about rsh ?

        Sending password in clear text is disturbing, even on a "trusted" network. I mean, it's so easy to do a tcpdump...

        With rsh you don't even need to (instead edit .rhosts). And IIRC there's a possibility to use crypto like kerberos to authenticate (but I don't use it on my home LAN), while data is still sent without encryption.
        • Host based access control is a very bad thing to do. It's very easy to spoof an IP as origin, and if you overload your switch with packets from spoofed IPs then you will end up with all packets being broadcast so you can set up a bi-directional connection.

          To the grandparent, the overhead of SSH is tiny. The time spent entering your password over telnet is going to be greater than the time spent doing a public key handshake on anything faster than a 486SX. If you are lazy, share private keys on all of yo

          • by alexhs ( 877055 )

            To the grandparent, the overhead of SSH is tiny. The time spent entering your password over telnet is going to be greater than the time spent doing a public key handshake on anything faster than a 486SX. If you are lazy, share private keys on all of your trusted machines.

            Exagerated. My home server is a Pentium 166 MX. I can exchange less than 10Mbps with ssh, while I can transfer a little more than 30Mbps with rsh unencrypted content. That's why I'm using rsh.

            About IP spoofing, remember I was comparing rsh to telnet, not to ssh. Kerberos requires authentification so IP spoofing won't be enough, and IP spoofing can be detected checking MAC address. MAC address can also be spoofed, but it becomes more difficult to do that without being detected than a tcpdump.

      • by Alioth ( 221270 )
        Good grief. Even my ancient VAX (circa 1988-1989) running OpenBSD will get you logged in with the latest version of ssh in a matter of seconds. Your cisco box, I suspect, is from the cretaceous period.

        You should encrypt on the LAN anyway unless there is a really good reason not to - many hacks/information thefts/destruction of data etc. is caused by company insiders. There is no such thing as a trusted network (except perhaps the network in your house). The expectation that a company LAN is secure has got m
      • by Cheesey ( 70139 )
        I actually find SSH faster, because I've got public key authentication set up and never have to enter a password. Because ssh-agent does all the authentication for me, I can log in to remote machines without any delay at all. Whereas with telnet I would have to enter a password. It would be equally fast to use rlogin with host based authentication, but the thought of using host based authentication makes me feel very ill.

        I just enter my passphrase after I log in (using ssh-add), and then ssh-agent manages t
    • Re: (Score:3, Informative)

      by drsmithy ( 35869 )

      Who the hell even THINKS about enabling telnet on any box these days?

      Sun, apparently, since it's enabled by default.

      • Considering the salary and experience requirements to get any sort of decent Solaris administrator, telnet being left open on any sort of non-legacy hardware can only be excused because of some ridiculous legacy application needs.
      • by dknj ( 441802 ) on Monday February 12, 2007 @10:24AM (#17982260) Journal
        except it's not... (at least not as of the 10/06 release)
        • Re: (Score:3, Informative)

          by jaymzter ( 452402 )
          I have 11/06, and believe me, I was surprised to find telnet enabled.
        • by arth1 ( 260657 ) on Monday February 12, 2007 @11:47AM (#17983306) Homepage Journal
          Since the exploit site didn't yet have information about older versions of Solaris/SunOS, I hope it can quench the panic for some when I say that only Solaris 10+ appears to be affected.

          If you're on Solaris 8 (SunOS 5.8 or Solaris 2.5.8) or 9 (SunOS 5.9, or Solaris 2.5.9), you appear to be safe.

          This is relevant because large companies seldom jump to the newer versions until they have to - for production systems, as long as the older versions are supported and working, that's more important than gambling on existing software still working if upgrading the OS. So there's an awful lot of systems with Solaris 8 and 9 out there, but luckily they appear not to be affected.
      • Re: (Score:3, Informative)

        by udippel ( 562132 )
        Whatever the SUNny fanboys have / had to say:
        Only in Solaris 10 11/06 was it disabled, and only if SBD was selected.
        This sheds a wholly new light on 'Secure By Default':
        Disabling telnet ! Yahoo ! - if SBD is set.
    • by imikem ( 767509 ) on Monday February 12, 2007 @09:52AM (#17981944) Homepage
      Relevant line from /etc/services:

      telnet 23/tcp imadumbass hackmenow rootrus rotflmao
    • by teslar ( 706653 ) on Monday February 12, 2007 @09:53AM (#17981958)
      I do. And then I sit down naked in the snow and castigate myself with a 9-tail as a punishment for these impure thoughts.

      Having said that, today is a good day to find out if that head of IT you never liked anyway has telnet enabled on one of his Solaris machines :)
    • Solaris 10 6/06 media-based installs think you should. It is enabled by default.
    • Who the hell even THINKS about enabling telnet on any box these days?

      And how many remember to run "pkgrm SUNWtnetd" to be sure.

    • towel.blinkenlights.nl, that's who.
    • by bockelboy ( 824282 ) on Monday February 12, 2007 @10:08AM (#17982082)
      Let me take a crack at this:

      1) Fermi National Accelerator Laboratory.

      That'll account for a couple thousand computers. It's left as an exercise for the reader to find other sites.

      Are they just crazy? I know that almost every single box at FNAL has the telnet daemon running, and is behind no firewall. Why aren't they hacked-to-death? Kerberos.

      FNAL has a policy that every service beyond central IT's web pages is protected by Kerberos. The Kerberos-enabled version of telnet is as secure as one can get; I've been told by their sysadmins that it is more secure than SSH because it is simpler and the network and authz/authn stacks are separated. So, historically, Kerberos-enabled telnet has had less bugs than SSH.

      Just because YOU don't run telnet (or don't know how to run it securely) doesn't mean that there aren't thousands of boxes out there that are secured by it.

      If there are actually any Sun boxes at FNAL (they were one of the original big adopters of Linux), you can bet they'll probably be turned off today...
      • Re: (Score:3, Informative)

        Just to nitpick, nothing is secured by telnet. Just because the login is "safe" doesn't mean that using an unencrypted protocol is ever a good idea.
        • Re: (Score:2, Informative)

          by Zan Lynx ( 87672 )
          I know of at least one large site that uses telnet and other unencrypted protocols. They do use password + token encrypted authentication, but that is the exception. Their security policies are Orwellian. Their IDS watches everything. Encrypted sessions are assumed to be evil, and are hunted down and killed. The rest is matched against statistical usage patterns and off-pattern usage is popped up to a security administrator with a complete session trace.

          That is all internal of course. Off-site access
          • by SatanicPuppy ( 611928 ) * <Satanicpuppy@g[ ]l.com ['mai' in gap]> on Monday February 12, 2007 @11:22AM (#17982984) Journal
            Sounds like they're more interested in watching their own employees than in securing their systems from external threats.

            If it were me I'd just log everything in every session (which is easy), and make the users use SSH. That way you can audit everything they do, every command they type, but still have a level of security. You have to remember that any user can sniff telnet traffic on the network, so forcing everyone to use telnet because you don't trust them means the ones who are untrustworthy have a better chance of stealing something useful from a coworker.

            Even better would be to hire trustworthy people and treat them as such in the absence of evidence to the contrary.
        • by evilviper ( 135110 ) on Monday February 12, 2007 @12:51PM (#17984162) Journal

          Just because the login is "safe" doesn't mean that using an unencrypted protocol is ever a good idea.

          You're right... No more secure websites for you, since HTTPS is just HTTP over an SSL data stream.

          You could just as easily use Kerberos to encrypt HTTP traffic as SSL, and that is indeed exactly what Kerberos does for just about any communications protocol...

          Kerberos telnet is as encrypted as it gets.
    • I don't think a lot of organizations are running telnet open to the Internet, but from practical auditing experience I can say that lots of companies have failed to disable telnet in their internal network(s). Their security model is focused on keeping the perimeter secure by firewalls, IDS and whatnot, but internally all their systems run default installs without any security hardening. They really haven't yet realized that multilayer security is a must these days also in the IT area.
    • by udippel ( 562132 )
      Who the hell even THINKS about enabling telnet on any box these days?

      It really beats me, how this is 'Insightful' as of now at +4 ??

      What also beats me, that a default install of Solaris 10 seems to have it open. Idiots. Was just sitting at one and saying to myself: Let's show it is harmless. And post to Slashdot. And voilà, there I was. Open. Fscking dimwits. No, it wasn't me opening it up. Can't you trust anyone these days ?
      I really adore Theo's resolve that boxes need to be unlocked instead of locked
    • by 99BottlesOfBeerInMyF ( 813746 ) on Monday February 12, 2007 @11:14AM (#17982852)

      Who the hell even THINKS about enabling telnet on any box these days?

      Sadly, a whole lot of people. I work for a company that makes very expensive and cool specialty servers that perform certain security related functions. As a security company, naturally we take care not to tarnish our reputation by leaving these servers vulnerable themselves. We try to encourage our customers to be moderately responsible as well, as any box can be made insecure. I know of at least on tier-1 ISP that has one of our boxes sitting publicly accessible with telnet enabled and no IP access restrictions.

      As for who uses telnet in general, most ISPs in Asia seem to use telnet to configure their systems via their control networks. Large financial institutions in Europe use telnet, as use of encryption is restricted on their trusted networks, for reasons of transparency to the stock regulating authorities. ISPs in South America often use telnet and provide shell accounts to customers. I'm sure there are more groups that use it for one reason or another.

  • Does ANYONE run telnet anymore? There has been no need to run telnet for at least 10 years. If you ARE nuts enough to run it, you would would be even more nuts to have it open to the internet. Can anyone confirm if telnet is enabled by default on Solaris for new installs? I would doubt it - I haven't seen telnet being enabled by default on any unix flavor in at least a decade.
    • Re: (Score:2, Informative)

      by Anonymous Coward
      Can anyone confirm if telnet is enabled by default on Solaris for new installs?

      It is on the 06/06 release of Solaris 10.
      • Time to sell Sun stock then (well, it's already in the toilet) because that is not just stupid, it's gross negligence.
    • Re: (Score:3, Informative)

      by Anonymous Coward
      Solaris 8, 9, 10 -- all have telnet, ftp, rlogin and others enabled by default at a clean install.
      You can check it for yourself in vmware, if you do not believe.
      • by Bert64 ( 520050 )
        Even such ridiculous services as chargen, echo and discard are turned on by default still.
      • Wow. That's an awful decision. Of course any decent admin will close down all unneeded services, but why have it all enabled by default? Is there any legitimate reason for that?
      • Comment removed based on user account deletion
    • I run telnet.... (Score:2, Informative)

      by dnormant ( 806535 )
      While I'm upgrading openssl or ssh. It's a pain getting lock out of a server and having to resort to the console. And, I never forget to disable it when I'm done.
  • not an excuse (Score:5, Insightful)

    by otacon ( 445694 ) on Monday February 12, 2007 @09:55AM (#17981970)
    "Nobody should be using it anyways" is not an excuse. If it is included, it should be held to the same standard as every other application. In some legacy cases I'm sure telnet is of some use. But regardless the fact that it has a practical use or not is irrelevant.
    • by LoadWB ( 592248 ) *
      Fully agree here. If it ships with the OS, it should be audited and maintained like everything else. I have a Solaris 7 box sitting out in the wild that I have to run in.telnetd on because the SSH daemon occasionally likes to die*, and inetd has never died on me. It's protected by tcp-wrappers and a Cisco ACL to allow only a single IP address to connect.

      * Might have to do with only having 64MB of memory available. Of course, there's security there, too -- the server has 2GB of hard drive space and 64MB
  • by petes_PoV ( 912422 ) on Monday February 12, 2007 @09:56AM (#17981986)
    First they say there's a bug with telnet passing switches through to login.
    Then they start a tirade against sending passwords in the clear.
    After that they say the fix is not to use telnet.

    Putting aside the holier (more secure) than thou attitudes here about telnet security. I've got to say that not using something because it's broken is never a fix (unless you're a manager). The fix is to mend the problem. In the meantime, maybe, avoid the service. but bear in mind, someone still has to fix it.

    • by Bert64 ( 520050 )
      Not using telnet is a valid fix...
      Telnet is a security risk, even if this bug were fixed. Telnet is still considered a risk on other systems which don't have this vulnerability.
    • by pla ( 258480 )
      First they say there's a bug with telnet passing switches through to login. Then they start a tirade against sending passwords in the clear.

      I would not suggest overlooking that GLARING flaw with telnet.

      Yes, we should consider this particular bug a serious flaw in need of repair. But it seems like something of an absurdity to worry about one critical security flaw while ignoring another just because it counts as a "feature" rather than a "bug".



      I've got to say that not using something because it's
  • This seems to be a good example of both the benefits and drawbacks of an open development model.
    The good news is that a third party has informed Sun of the info, who will now fix it.
    The bad news is that we have no idea how long people have known about this problem...
    • Re: (Score:3, Insightful)

      by pipatron ( 966506 )

      The bad news is that we have no idea how long people have known about this problem...

      But in a closed development model we would have some magic insight in how long people have known about a flaw? I'm sorry, but I fail to see the drawbacks in this case.

    • by Bert64 ( 520050 )
      I'm sure people have known about it for quite a time...
      Being open won't have helped in this case, people found an almost identical issue in AIX 3, which is closed. I wonder how many enterprising script kiddies went trying to exploit the AIX vulnerability, and accidentally got into a Solaris machine.
  • 0-day? (Score:3, Interesting)

    by Aladrin ( 926209 ) on Monday February 12, 2007 @10:07AM (#17982056)
    Maybe I'm just confused, but doesn't '0-day' mean the exploit was found the day the code in question was released?

    I generally don't follow Solaris, and 11 might have just come out, but I seriously doubt 10 and 11 both came out at the same time.
    • Re:0-day? (Score:5, Informative)

      by walt-sjc ( 145127 ) on Monday February 12, 2007 @10:13AM (#17982146)
      No, zero day means that an exploit was released before or on the same day as the vendor / community found out about it. Ethical security researchers notify the vendor first, and at LEAST give them a few days / weeks to resolve the problem before releasing the full details to the public.
    • by jmv ( 93421 )
      No, it means the exploit came in 0-day after the patch, i.e. you're screwed even if you're up-to-date with the security patches.
    • "0-day" has become nothing more than a buzzword.
    • by db32 ( 862117 )
      In terms of warez 0-day is 0 days from release it was warezed. In terms of security its a little different. 0-day vulnerability is misleading at best, but since when have slashdot headlines been accurate? 0-day exploits are exploits released 0 days from discovery of the vulnerability as opposed to exploit code showing up 30 days after the owner was notified and has a chance to fix it. So you can have 0-day exploits from code that is 10 years old. This is in a sense also related to the stupid hacking ch
    • by Yenya ( 12004 )

      Maybe I'm just confused, but doesn't '0-day' mean the exploit was found the day the code in question was released?
      Nope. `0-day' means that the vulnerability (with the exploit) is made public before (or the same day) the vendor patch is available. See http://en.wikipedia.org/wiki/0_day [wikipedia.org], section "Exploits and vulnerabilities".
  • The Exploit (Score:4, Informative)

    by biftek ( 145375 ) on Monday February 12, 2007 @10:37AM (#17982400)
    Since noone seems to have bothered posting it yet, "telnet -l -frandomuser randomsolarishost".

    So stupid.
  • Coming from a dot-com background, it was a given that telnet was disable and replaced with OpenSSH or something similar. I'm amazed though at how many large companies are still running telnet. Sure, they have most of their servers behind firewalls, but since the largest number of breakins are still attributed to internal hacks telnet needs to be considered obsolete.
  • by jaymzter ( 452402 ) on Monday February 12, 2007 @11:02AM (#17982712) Homepage

    rhlinux1:~$ telnet -l"-froot" solaris
    Trying 172.16.141.27...
    Connected to solaris.example.com (172.16.141.27).
    Escape character is '^]'.
    Not on system console
    Connection closed by foreign host
    This is basically a vanilla install.
    • Re: (Score:3, Informative)

      by Anonymous Coward
      telnet -l"-fbin" solaris
  • by kentrel ( 526003 ) on Monday February 12, 2007 @11:05AM (#17982756) Journal
    To: You Unix Communists
    From: Steve Ballmer
    Subject: Pwned
    Body:
    Microsoft:1 - Unix: NIL LOLOLOLOLOLOL!!!!!!!111


    :)
    Love Steviepoo

  • ... if there is a single unix admin running telnetd on a non-firewalled, internet-connected machine they deserve to be shot, until they are dead.

    ... and then shot again.

  • by Greyfox ( 87712 )
    I bet this is still a problem on most other flavors of commercial UNIX, too. I found it for DG/UX back in '96 while reading the source code to their telnet server (I was doing security auditing for them at the time.) Their server was pretty much unmodified from the original AT&T code. The fragmented UNIX industry insures that this problem keeps cropping up even though it's been documented for a solid decade now. And what's worse, most UNIX vendors still ship their machines with telnetd enabled.

    Data Ge

  • This bug is for Solaris telnet only, correct? So MUDs and others which are using the protocal without telnetd are ok?
    • Re: (Score:3, Informative)

      by fizbin ( 2046 )
      Short answer: yes

      Long answer: Even if there were a breach in the security of your mud, it would only allow access as the user running the mud daemon. Usually that isn't root. (with telnetd, of course, it usually is root)

      Longer answer: The specific vulnerability here covers the way that telnetd passes arguments to the program login. Specifically, it passes what telnetd thinks is a parameter, but login interprets the passed result as an option. Presumably, your MUD server isn't turning around and calling
  • by BrianRoach ( 614397 ) on Monday February 12, 2007 @12:28PM (#17983870)
    When you install Solaris 10, you are prompted for how you want remote access to the box initially configured. This is done in phase 1 of the install, running off the install media.

    You can either turn on everything (telnetd, ftpd, etc, etc), or only have sshd running when the box comes up for the first time.

    So saying that telnetd is on "by default" isn't exactly correct, unless your definition of "by default" is "explicitly enabled".

    - Roach

It is easier to change the specification to fit the program than vice versa.

Working...