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.
A proper fix for this would change the name of that EXCEPTION_RAISE macro to something that doesn't suggest out of sequence execution.
Someone should grep through the source for lsh, and see if there are any other places where after this macro is called, the code really is expecting execution to continue inline.
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
Because GNU Ish was created before OpenSSH. It's as simple as that.
There's always Dropbear, which seems fairly small and useful, and does SSH2.
Mmmmm. monoculturelicious.
If monocultures are bad, then why does the 'linux camp' only advocate Linux? Why do firms that have names for parts of them like the Open Source Development Network or Open Source Development Labs spend their money on GNU/Linux - thus creating a new monoculture?
Someone has to focus on it. There will always be those groups of people who want to specialize in one area, and advocate the same specialization. But that's ok, as long as there are different groups doing different things. When everyone starts doing the same thing *cough* Windows *cough*, then we have a problem.
#!/
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.
In the wake of the recent OpenSSH exploit, mostly because I couldn't find OpenSSH 3.7p1.
It was -- there's no other way to put this -- a massive, massive, massive pain in the ass. Wanted a bunch of additional stuff installed before it would compile, and, when it finally did compile, the default installation bore no resemblence to an sshd (in the sense of, you know, accepting ssh connections). I finally just gave up and went looking more actively for the patched OpenSSH.
Yes, yes, I know, I'm just too dumb to realize how great it actually is. All I'm saying is, as a drop-in replacement for OpenSSH, lsh comes up, well, short. It badly needs (1) to have its prerequisite packages streamlined and, if possible, eliminated, and (2) to work like SSH by default.
Of course, if the goal is to have a package that kinda works like SSH if and only if you know how to make it do so, there's not much work to do.