Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenSSH Local Root Hole

Posted by michael on from the say-it-ain't-so dept.

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

3 of 490 comments (clear)

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

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

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