Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Solaris Telnet 0-day vulnerability

Posted by Hemos on Mon Feb 12, 2007 09:40 AM
from the frantically-trying-to-fix dept.
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."
+ -
story

Related Stories

[+] Worm Exploiting Solaris Telnetd Vulnerability 164 comments
MichaelSmith writes "Several news sites are reporting that a worm is starting to exploit the Solaris Telnet 0-day vulnerability. By adding simple text to the Telnet command, the system will skip asking for a username and password. If the systems are installed out of the box, they automatically come Telnet-enabled. 'The SANS Internet Storm Center, which monitors Internet threats, has noticed some increase in activity on the network port used by Solaris' telnet feature, according to an ISC blog posted on Tuesday. "One hopes that there aren't that many publicly reachable Solaris systems running telnet," ISC staffer Joel Esler wrote.'"
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • 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)

      Well, according to TFA, nobody should.
    • 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.
        • 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.
              • 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.
                • by bugnuts (94678) on Monday February 12 2007, @12:35PM (#17983934) Journal

                  Security best practices are the same whether you're talking about securing your home network or a military network
                  No. It's not. The only thing those have in common is considering what you are protecting, and how much risk you wish to take versus the convenience granted. The specifics are immaterial.

                  The OP is right, he knows his risks and has deemed it acceptable. You and others, having no idea of the risk, deem it unacceptable and are the ignorant ones.
        • by mi (197448) <mi+slashdot@aldan.algebra.com> on Monday February 12 2007, @10:23AM (#17982246) Homepage

          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.

    • Re: (Score:3, Informative)

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

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

      • 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)
        • 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.
    • 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 :)
    • 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...
        • 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.
          • by SatanicPuppy (611928) * <Satanicpuppy&gmail,com> 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 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.

  • not an excuse (Score:5, Insightful)

    by otacon (445694) on Monday February 12 2007, @09:55AM (#17981970) Homepage
    "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.
  • 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.
  • 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.
    • by walt-sjc (145127) on Monday February 12 2007, @10:08AM (#17982080)
      Since apparently Sun is negligent enough to have telnet enabled by default, it is an important story. This reminds me of the old NT4 days, where every service on the machine was enabled by default, and the first thing you had to do was turn everything off. Come on Sun, get with program here...
      • by zdzichu (100333) <[zdzichu] [at] [irc.pl]> on Monday February 12 2007, @10:54AM (#17982630) Homepage Journal
        The article talks about Solaris 10 u1 released in 2005. The latest thing is u3, which has two things:

        1) this attack does not work:

        Escape character is '^]'.
        Not on system console
        Connection closed by foreign host.

        2) when installing U3 one can opt to close most services. This could be also done after installation with "netservices limited" command.
        • by moyix (412254) on Monday February 12 2007, @11:56AM (#17983432) Homepage
          This is only because root is not allowed to log in remotely by default. "-fanyotheruser" will still work. I believe the current favorite is "-fbin". Also, if you've commented out the console line in /etc/default/login, it will allow access to root.

          This has been confirmed on the latest version of Solaris 10.
    • 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.