Slashdot Mirror


OpenSSH Local Root Hole

maelstrom writes: "Looks like someone's found a local root exploit for OpenSSH versions between 2.0 and 3.0.2. Seems as though its a one-off error, there is no public exploit, but there is sure to be one shortly. They aren't ruling out remote exploit. Recommending patching and upgrading ASAP."

10 of 490 comments (clear)

  1. Re:linux patch available by MrDingDong · · Score: 4, Informative

    Its out there - at least on ftp.openssh.com. I built and installed 3.1p1 a couple of hours ago on Linux.

  2. Correction: off-by-one by MarkusQ · · Score: 5, Informative
    Seems as though its a one-off error

    One-off: Something done intentionally but with no intention of repeating; a custom product, sample, or prototype.

    Off-by-one error: An error in enumeration, such as starting or ending a count at the wrong value (e.g. 0 vs. 1), counting the starting/ending value in a cycle twice or not at all (e.g. in counting a group of people which includes yourself), counting delimiters as opposed to the items delimited (e.g. the "fence post" problem), or any analogous error.

    These are rather different! When I read the abstract my first thought was "how can they determine that?"

    -- MarkusQ

  3. OpenSSH site already updated? by Noryungi · · Score: 4, Informative


    Here is what can be found on their web site:

    "OpenSSH 3.1 released March 7, 2002."

    Hmmm... That was quick! Especially since the advisory reads:

    Pine Internet Security Advisory

    Advisory ID : PINE-CERT-20020301
    Authors : Joost Pol
    Issue date : 2002-03-07
    Application : OpenSSH
    Version(s) : All versions between 2.0 and 3.0.2


    Pretty good job.

    --
    The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
    1. Re:OpenSSH site already updated? by sheetsda · · Score: 4, Informative
      OK, I'll bite.

      The OpenSSH people corrected the bug in their own source, which they would have had access to even if it was closed.

      Sure, if they found out about it before a blackhat did. There's a good chance they wouldn't have. And anyone could've corrected the issue and submitted a patch; in OSS there may be a patch before the public even knows there was a vulnerability.

      The vendor was notified ahead of time, which is one of the things that MS has been campaigning for. Why aren't we beating up on the guy who released this to the vendor first and not to the community immediately?

      There's a policy among bug reporters to give the author a reasonable period of time to fix a bug before releasing it. MS gets that grace period about as often as everyone else, but they're so slow at getting out patches that the vulnerability runs rampant. If an OSS project is slow at getting patches out, someone else takes it upon his or herself to write a patch. Its sort of a self-correcting system.

  4. smallest possible patch by bill_mcgonigle · · Score: 4, Informative

    For you guys too lazy to read:
    http://www.pine.nl/advisories/pine-cert-20020301.t xt
    ( I was going to post the patch here, it's really small, but apparently slashcode doesn't know what the blockquote tag is for, despite claiming it's supported)

    But this isn't just an attempt at karma whoring, there is a point. When a single missing '=' can cause a root exploit in code that's generally considered well-written, who are these people that actually entertain the idea that Microsoft secured their software over the last month?

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  5. OpenBSD upgrade. by saintlupus · · Score: 4, Informative

    OpenSSH 3.1 was released this morning. The info and tarball for OpenBSD systems is available at:

    http://www.openssh.com/openbsd.html

    Mine's compiling now.

    --saint

  6. FreeBSD affected; patches available by Dom2 · · Score: 4, Informative

    Unfortunately, I can't post the advisory here due to the lame lameness filter. But here are the patches:

    ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/S A- 02:13/openssh.patch
    ftp://ftp.FreeBSD.org/pub/Fre eBSD/CERT/patches/SA- 02:13/openssh.patch.asc

    Execute the following commands as root:

    # cd /usr/src
    # patch < /path/to/sshd.patch
    # cd /usr/src/secure/lib/libssh
    # make depend && make all
    # cd /usr/src/secure/usr.sbin/sshd
    # make depend && make all install
    # cd /usr/src/secure/usr.bin/ssh
    # make depend && make all install

    If you've got the ssh port installed, check out the advisory for details on what to do:

    http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0 +c urrent/freebsd-announce

  7. Re:Please stop writing network apps in C! by abaptist · · Score: 5, Informative

    If you look further down in the patch, it then references an array with offset 'id'. In a language like Java this would throw an ArrayIndexOutOfBounds exception, NOT read random memory and possibly cause a crash.

    So in fact a stricter language would fix this problem.

  8. FYI: my box may have been exploited by this by umoto · · Score: 4, Informative

    Two weeks ago my Mandrake box, connected to a cable modem, was rooted. The only port open to eth0 was ssh (openssh-3.0.2p1). I analyzed the logs and they indicated someone had spent an hour trying to exploit various SSH bugs that have been fixed in the past. Then there was an 8 minute pause before "linsniffer" was installed and eth0 went into "promiscuous mode".

    I haven't been able to verify openssh-3.0.2p1 was truly the cause, but it seems likely. This may have been the remote root exploit which the advisory "does not rule out".

  9. Re:*** Help on upgrading a remote server? by Bluecoat93 · · Score: 5, Informative

    Known to work on Solaris, OpenBSD, and Linux. YMMV elsewhere, but it should work fine.

    1) Use SSH to log into your server.

    2) Install the new ssh version. Your old version is in memory, so replacing the binary won't have any adverse effect on your connection.

    3) Run 'ps -ef | grep sshd' or 'ps auxw | grep sshd' (depending on your UNIX flavor)

    4) find the sshd instance with a parent process ID of '1' -- this will be the actual daemon spawend by init. The other process will be the one spawned by sshd itself to handle your connection.

    5) kill

    6) the parent sshd process will terminate, but yours will stay running

    7) start up the new sshd

    8) from another workstation or window telnet to port 22 on your server and verify that the version number reflects the new version.

    9) from another workstatino or window, ssh into your server to make sure you still have access.

    10) close your original ssh session

    I've used this exact process to upgrade many machines at remote locations. As long as you verify that the new sshd is running before you close your existing connection, you should have no problems.