Slashdot Mirror


Remote Root Exploit In lsh

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

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

  2. Re:Telnet by daeley · · Score: 3, Informative

    Just like good posts don't require logical operators that actually exist.

    And anal rejoinders don't require snooty pseudo-knowledge that's actually wrong.

    --
    I watched C-beams glitter in the dark near the Tannhauser gate.
  3. 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.

  4. Re:After 20+ years of buffer overflow exploits... by fw3 · · Score: 3, Informative
    There are several available solutions to this

    Libsafe, one of the oldest use LD_PRELOAD to replace the dozen-odd most often problematic library functions with safe/checked versions. It's been available for several years. Requires no code modifications (beyond setting the LD_PRELOAD env).

    Propolice, stackguard, patches to Gcc / kernel provide various stack protections. Propolice has been built into OBSD for about a year now. These require object recompilation. PaX provides various randomizations thru the kernel. All fo these significantly complicate the attakers task.

    --
    Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
    bsds are of course just BSD
  5. 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.

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