Slashdot Mirror

← Back to Stories (view on slashdot.org)

Remote Root Exploit In lsh

Posted by timothy on from the harsh-eye dept.

skookum writes "After last week's OpenSSH patch-fest, a lot of people suggested GNU lsh as a replacement. Unfortunately, it seems that the lsh team has recently discovered a heap overflow bug of their own that can lead to compromise. An exploit was posted to BugTraq two days ago. Happy patching."

4 of 445 comments (clear)

  1. Re:Telnet by runderwo · · Score: 4, Informative
    I seriously think that we need to take some time to consider how Open Source projects do security. The "more eyes" mantra doesn't cut it.
    Um, how do you think this problem was spotted? Read the mailing list post. There was a pair of eyes that found the bug, and he subsequently posted to the list.

    In addition, a fix was checked in within four hours. 14 hours later, exploit code was posted to SecurityFocus, in the afternoon. Any admin who checked the lsh mailing list in the morning would have seen the error and the fix, and been well ahead of the exploit.

    --
    LRC, the best-read libertarian site on the web
  2. Re:Can someone explain to me why.. by lcs · · Score: 5, Informative

    I, like the author of lsh, is a member of the same
    computer society, Lysator, and I happen to remember
    reading about the early lsh developments.

    It was started in August 1998, and that's as far
    as I know, several months if not years before
    OpenSSH was started.

  3. Yet another SSH server by Anonymous Coward · · Score: 4, Informative

    There's always Dropbear, which seems fairly small and useful, and does SSH2.

    Mmmmm. monoculturelicious.

  4. Re:Telnet by groomed · · Score: 4, Informative

    Sigh. The language card again. OK.

    Java. Won't have any double-free bugs or stack-smashing attacks. But offers great potential for deadlock bugs due to the braindead IO model. And explodes in out of memory situations -- not unlikely given the tens or hundreds of MBs the Java runtime consumes. Further exacerbated by the ease with which memory is leaked. Then there are the subtle but devastating differences between the various Java runtimes. As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).

    Yeah. Java.