Slashdot Mirror


Solaris Telnet 0-day vulnerability

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."

19 of 342 comments (clear)

  1. Why is this a big deal? by nettdata · · Score: 5, Insightful

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

    --



    $0.02 (CDN)
    1. Re:Why is this a big deal? by TheGratefulNet · · 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.

      --

      --
      "It is now safe to switch off your computer."
    2. Re:Why is this a big deal? by SatanicPuppy · · 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 to come along and steal your user info.

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
    3. Re:Why is this a big deal? by walt-sjc · · Score: 2, Insightful

      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.

    4. Re:Why is this a big deal? by mi · · Score: 5, Insightful

      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.

      --
      In Soviet Washington the swamp drains you.
    5. Re:Why is this a big deal? by Anonymous Coward · · Score: 1, Insightful

      Hard, crunchy outside... Soft, chewy inside!

    6. Re:Why is this a big deal? by SatanicPuppy · · Score: 3, Insightful

      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.

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
    7. Re:Why is this a big deal? by arth1 · · Score: 4, Insightful

      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.

    8. Re:Why is this a big deal? by bugnuts · · Score: 4, Insightful

      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.
    9. Re:Why is this a big deal? by SatanicPuppy · · Score: 2, Insightful

      You are so wrong. The difference is, on the one hand, taking a risk for zero gain on an obsolescent standard, and on the other hand, using the application that is pretty much the standard for this type of communication! You keep acting like there is some kind of mystical benefit to using telnet, and there's just not. What are you guys using 2800 baud modems? What's the worst case with SSH? The encryption can be compromised...making it the same as fricking telnet!

      Hmmmm. Decisions, decisions, decisions.

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
    10. Re:Why is this a big deal? by SatanicPuppy · · Score: 2, Insightful

      1) Putty is free, stable, and easy to use.
      2) service telnetd stop;service sshd start
      3) Hitting "Y" one time is too much bother for you?
      4) Non-issue on all but the slowest hardware.
      5) I don't see how that is a benefit...

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
  2. not an excuse by otacon · · Score: 4, Insightful

    "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.

    --
    In a world of acronyms, the words are the real victims.
  3. the authors seem very confused ... by petes_PoV · · Score: 3, Insightful
    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.

    --
    politicians are like babies' nappies: they should both be changed regularly and for the same reasons
  4. Re:OpenSolaris as a development model by pipatron · · Score: 2, Insightful

    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.

    --
    c++; /* this makes c bigger but returns the old value */
  5. Re:Here come the fanboys by Rob+T+Firefly · · Score: 2, Insightful

    Wtf uses telnet anymore, unless they're dealing with the most legacy of legacy crap.
    I'll bet more of the IT-based Slashdotters than would like to admit are forced to support, or at least deal with, the most legacy of legacy crap now and then.
  6. telnetd NOT on "by default" in Solaris 10 by BrianRoach · · Score: 2, Insightful

    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

  7. Re:Here come the fanboys by geoffspear · · Score: 2, Insightful

    If that MUD is using telnetd instead of using its own socket code, it may not be "the most legacy of legacy crap" but it's certainly the worst MUD software ever written.

    Although I suspect you just have no idea what you're talking about and it's not doing that.

    --
    Don't blame me; I'm never given mod points.
  8. Re:Here come the fanboys by annodomini · · Score: 2, Insightful

    The thing is, you can tunnel pretty much anything over anything, and telnet would be pretty easy to tunnel over. In fact, if you really wanted you could tunnel SSH over Telnet, and retain the encryption. So, there is absolutely no reason to leave Telnet unblocked and SSH blocked. Furthermore, in an institutional environment like a school, you could just not install SSH clients, and not give the students sufficient privileges to run their own, which is more effective than blocking particular ports. As long as the users can run arbitrary software, or an SSH client that's already installed, they can just use a different port for SSH to get around a firewall block.

    Basically, there is no way in which Telnet is more secure, and leaving a Telnet port open with an SSH port blocked will always harm security more than it will help.

  9. Blocking ports- a poor excuse for packet shaping by Kadin2048 · · Score: 2, Insightful

    I hope you block ports 80 and 443, too, because otherwise it's still trivial to create an SSH session to the outside. All the enterprising student must do, is configure their (parents') home firewall, to forward outside port 80 to LAN port 22 on their PC. It's no more difficult really than just opening up port 22 bidirectionally. Then it's just "ssh -p 80 -D 8080 joestudent@mypc.dyndns.org"

    If you want to filter, get a packet shaper and stop using ports; all you do by blocking ports is encourage people to abuse port 80 and other well known service ports, and make diagnostics more difficult. Unless the goal is just to give the semblance of censorship while making it as easily avoidable as possible, which is arguably laudable, but in that case why bother to block port 22 in the first place.

    And before anyone makes the argument about blocking ports making it more difficult for 'casual' users, even a casual user is capable of reading Google, or asking a smarter user what to do. A few years ago, I witnessed what happened on a campus LAN when the admins inadvertently mis-configured the firewalls and blocked port 5190, which is used by AIM. Within twenty minutes, there were emails circulating which included screenshots and step-by-step instructions on how to change the AIM client to use port 80 instead. Hundreds, if not thousands of students, who didn't even know what port was, were able to follow one person's instructions and get around the problem. (It turns out it wasn't an intentional block, but just a mistake; however, the result was that half of the student machines ended up running AIM over port 80 forevermore.) It only takes one user with enough brains to read a manpage, and a desire to score some points with other students by showing them how to get around the block, to torpedo port-based blocking.

    --
    "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."