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."
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
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.
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.
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
There's always Dropbear, which seems fairly small and useful, and does SSH2.
Mmmmm. monoculturelicious.
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.