Slashdot Mirror


New Vulnerabilities in Portable OpenSSH

An anonymous reader writes "The OpenSSH team has uncovered multiple exploitable vulnerabilities in the days-old portable release of OpenSSH. That's right folks: time to patch *again*. 3.7.1p2 is now available. Instructions and mirror list here. Please note that this vulnerability only affects *portable* OpenSSH--so if you are running OpenBSD, you're safe. This vulnerability apparently has to do with PAM, so you can use the 'UsePam no' option in your config file. Info on the advisory here and here."

22 of 324 comments (clear)

  1. Non-standard configuration by grub · · Score: 5, Informative


    From the article: At least one of these bugs is remotely exploitable (under a non-standard configuration, with privsep disabled)

    Priviledge Separation saves the day again. I think this is a testament to the forward thinking of the OpenBSD and OpenSSH people: they know that human error introduces potentially exploitable bugs, hence the work that went into PrivSep to minimize the risk.

    "The lengths some people will goto to try and damage Theo's pride" Most moronic submitter comment ever.

    --
    Trolling is a art,
    1. Re:Non-standard configuration by Frymaster · · Score: 4, Insightful
      writers looking for a typewriter-with-memory would be better served by Notepad or the Mac equivalent.

      your belt may fail
      your suspenders may fail

      if you're really serious about keeping your pants up, use both!

      this is the theory of theo-n-the-openbsd-cats. you used priv sep plus all the other security goodies.

      you don't say that doing nightly backups is a "weak" practice because the backups could fail at the same time as your main drive. do you?

    2. Re:Non-standard configuration by grub · · Score: 5, Insightful


      Having a small amount of the sshd code running as root with the 'sshd' user handling the rest helps make it harder for other exploits. I don't think anyone would suggest that PrivSep makes an exploit impossible, but it is another great layer on the security-onion.

      --
      Trolling is a art,
  2. hmm by tedtimmons · · Score: 4, Funny

    Who is pam, and what did she have to do with openssh?

    -ted

    1. Re:hmm by r_j_prahad · · Score: 4, Funny

      Pam was my ex-wife. She was pluggable by too many.

  3. A solution? by gpinzone · · Score: 4, Funny

    This vulnerability apparently has to do with PAM, so you can use the 'UsePam no' option in your config file.

    Wouldn't that prevent anyone from loging-in? I guess that's a solution. Why not disconnect the network cable, too?

  4. Time for a new spin on security practices? by Anonymous Coward · · Score: 4, Funny

    Maybe the OSS community needs a Trustworthy Computing initiative =]

    1. Re:Time for a new spin on security practices? by ninewands · · Score: 5, Insightful
      OpenSSH... A Microsoft product, right? Oppss... Forgot, one can not criticize open source on the same standards we hold "M$"

      Well, yes, we should hold them both to the same standard ... so when Microsoft starts announcing it's own self-discovered vulnerabilities and releasing Day-Zero patches to fix them I will be just as critical of OpenSSH security as I am of Windows *cough*security*cough*.
    2. Re:Time for a new spin on security practices? by evought · · Score: 5, Insightful

      Also, notice that this is a problem which *may* be remotely exploitable in a *non-standard configuration*, when certain default security measures have been *disabled by the user*.
      This is not in the same league as "Oops, we left the RPC port open and rootable by default."

      The class of errors being fixed by OpenSSH is very different and the design takes security much more seriously.

  5. PAM is not in by default by Anonymous Coward · · Score: 4, Informative

    Before we all panic, note that PAM is not in the default build.

    It's also not in slackware builds (thanks Patrick).

  6. Re:I don't understand by Compenguin · · Score: 4, Informative

    From the portable openssh website:
    "Normal OpenSSH development produces a very small, secure, and easy to maintain version for the OpenBSD project. The OpenSSH Portability Team takes that pure version and adds portability code so that OpenSSH can run on many other operating systems (Unfortunately, in particular since OpenSSH does authentication, it runs into a *lot* of differences between Unix operating systems)."

  7. OpenSSH in RedHat 9 and others by avij · · Score: 5, Informative

    The RH-supplied latest OpenSSH (3.5p1-11) doesn't seem to accept the "UsePam no" directive that was suggested as a workaround, so if you go ahead and add that line to your /etc/ssh/sshd_config and say "service sshd restart", SSH will complain about an invalid configuration option and refuse to start. Just for your information..

    --

    Follow your Euro bills at EBT
    1. Re:OpenSSH in RedHat 9 and others by virtual_mps · · Score: 4, Informative

      More importantly, the problem only affects OpenSSH 3.7p and 3.7.1p, so adding "UsePam no" to a 3.5p installation is unnecessary.

  8. Re:JEBUS by Kalzus · · Score: 5, Insightful

    Arguably, this announcement *is* the result of an increase in code vetting on the part of the portable OpenSSH team. Just a thought.

    --
    "The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
  9. RedHat boxes are safe by menscher · · Score: 4, Informative

    Just to alleviate some of the panic, RedHat boxes are safe.

    1. Re:RedHat boxes are safe by MSG · · Score: 4, Insightful

      Please don't post links to bugzilla. Bugzilla is a database driven application, an linking to it directly from slashdot will certainly swamp that system. The information in the bugzill entry is:

      Opened by mjc@redhat.com (Mark J Cox, Security Response Team Lead) on 2003-09-23 11:16

      http://www.openssh.com/txt/sshpam.adv came out on Sep23 with two new
      vulnerabilities that affect OpenSSH.

      Both these issues only affect OpenSSH 3.7 and 3.7.1. Red Hat Linux and Red Hat
      Enterprise Linux are not vulnerable to these issues as we ship with earlier
      versions (with the addition of backported security fixes for other issues).

      Keeping this bug open for a few days to enable users searching bugzilla to find
      out that they are not vulnerable.

  10. New Motto by Greyfox · · Score: 4, Funny

    15^H^H10 minutes without a remote root exploit!

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  11. Yippee! by mrpuffypants · · Score: 4, Funny

    oooh! Patching every other day is fun!

    This is just like being a MCSE! Now I can hang out with the NT guys and chat about patching!

  12. Re:Just like MS then. by phliar · · Score: 4, Insightful

    With MS, they're gaping holes that we hear about because the worm actually did do the damage. The bugfixes for OpenSSH are all questions about bugs being found by reading the code, and nonstandard installations -- not known compromises. The speed with which security issues are handled is also much better than anything those yahoos ever do.

    --
    Unlimited growth == Cancer.
  13. fact of life by NumLk · · Score: 4, Insightful

    I'm not trying to be a tool here, but seriously, does anyone ever expect any piece of software to be 100% foolproof? Software is complex, and in its complexity lies opportunity for problems to arise. Sometimes they are simple coding mistakes, sometimes they are problems that arise when the software isn't used as its developers envisioned.

    As users of software though, it is irresponsible to assume that just because it is commercial, open source, MS, non-MS, or whoever is the messiah of the day's product that it will never have unexpected problems. Admittedly, some companies software appears to be worse than others, but that is the gamble we take when we build complex systems.

    --
    Children in the backseats don't cause accidents. Accidents in the back seats cause children.
  14. Re:Is the default config file safe? by Ratcrow · · Score: 4, Informative

    No!

    From the top of sshd_config:

    "The strategy used for options in the default sshd_config shipped with OpenSSH is to specify options with their default value where possible, but leave them commented. Uncommented options change a default value."

    In other words, simply uncommenting the line changes nothing -- the default is shown commented. For the SRPMS of OpenSSH-3.7p1, UsePAM is set to Yes.

  15. "Patch *again*" == no big deal by psyconaut · · Score: 5, Insightful

    The poster seems to insinuate that patching again is a chore...security is, by very nature, a moving target. I'm *glad* they find vulnerabilities and post regular patches...proves to me, at least, that somebody is on-the-ball.

    Heck, just be thankful they don't belong to the Microsoft school of security and fixes ;-)

    -psy