Slashdot Mirror

← Back to Stories (view on slashdot.org)

New ssh Exploit in the Wild

Posted by CmdrTaco on from the brace-for-impact dept.

veg writes "In the last few hours there have been several reports of a new ssh bug, with an exploit seemingly in the wild. Oh god not again... The lengths some people will goto to try and damage Theo's pride." Update: 09/17 00:24 GMT by T : friscolr writes "Hot on the heels of rev 1 of the buffer.adv advisory, here is revision 2, which fixes more than revision 1 did. Also see the 3.7.1 release notes."

3 of 754 comments (clear)

  1. Questions. by grub · · Score: 5, Interesting


    I have to wonder if UsePrivilegeSeparation was enabled. (see the manpage)

    One message in the thread indicates it is but this isn't first-hand knowledge. If PrivSep was enabled then is OpenBSD immune to this attack due to other parts of the OS being hardened (much like the zlib hole a few months back)? Also are these default installations or are they "tweaked"? As an aside, PermitRootLogin defaults to enabled, something I always disable as I have no need for it.

    Even if this does count as a new remote hole in OpenBSD, it's still a phenomenal track record they can be proud of.

    --
    Trolling is a art,
  2. Suggestions for a newbie? by johnny1111_23 · · Score: 5, Interesting
    Am pretty new to Linux, and am currently running a Lindows 4.0 installation my dad put on my computer.

    How worried should I really be about this? And what steps should I be taking (or ask dad to take)? Since I gather Lindows is similar to Debian, should I just look for a Debian tutorial?

    Thanks in advance.

  3. Re:Mirror of the vulnerability description by coyul · · Score: 5, Interesting

    The bug must center around this line:

    /* Increase the size of the buffer and retry. */
    buffer->alloc += len + 32768;

    It looks like the problem here is that buffer->alloc (which presumably stores the size of the buffer) grows on every try, while the actual size of the buffer grows only on successful tries. So you could have a situation where, after a couple of tries, the buffer is 65536, but buffer->alloc is 98304. This could potentially cause another part of the program to run past the actual end of the buffer.

    The patch addresses this by only updating buffer->alloc after the new memory has been successfully allocated.