Slashdot Mirror
OpenSSH Local Root Hole
maelstrom writes: "Looks like someone's found a local root exploit for OpenSSH versions between 2.0 and 3.0.2. Seems as though its a one-off error, there is no public exploit, but there is sure to be one shortly. They aren't ruling out remote exploit. Recommending patching and upgrading ASAP."
I assume it wouldn't be as it's on a different code base, then again 'assume means making an ASS out of U and ME'
Script kiddiesprobably has known about this for a while. Full diclosure is not only a way to get the word out so that it can be quickly patched (which apparently it already is) but also a way to kind of force people into an upgrade. That way no one with an old version of ssh is sitting there being unknowingly used for DDOS attacks because they didn't know he needed to upgrade.
Full disclosure has its downsides,but the upsides pretty much cancel them out.
Derek Greene
I'm sure it's more than the last three. Really, how many new features does SSH need? Bugs in an application of this type that is as mature as SSH tend to be security related. It actually makes me feel better that they're quickly responding to security bugs and doing new releases because of it.
Derek Greene
How did it cope with 18,000 simultaneous connections? Did you use mmap(), sendfile() and friends on linux to get the best performance possible? How did the xfer rates compare?
BTW, 24,000 lines is a hell of a lot. If you want to compare like for like, have a look at vsftpd by Chris Evans. It's written entirely in c. Have a read of the source - it's quite interesting how it has been done. I would be surprised if you could find a buffer overflow.
I actually do agree with your points mostly, but I would say "Don't use c for network apps unless you have a good reason to" and also "don't use c for network apps unless you _really_ know the hazards"
In some ways SSH is a special case anyway. It has all the intensive maths stuff to do for the session key generation etc. Not a good idea to code that in (eg.) perl imo.
BTW, out of interest, what is your "favorite modern language" ??
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Did you even look at the patch?
--- channels_old.c Mon Mar 4 02:07:06 2002
+++ channels.c Mon Mar 4 02:07:16 2002
@@ -151,7 +151,7 @@
channel_lookup(int id)
{
Channel *c;
- if (id < 0 || id > channels_alloc) {
+ if (id < 0 || id >= channels_alloc) {
log("channel_lookup: %d: bad id", id);
return NULL;
}
You want to explain to me how any "modern safe language" is going to stop me from saying 'greater-than', when I really mean 'greater-than-or-equal-to'?
Errrrrm
Isn't it a bit dogey just grabbing and installing a binary (rpm) from an untrusted source (ie you) for security software like SSH ?
I'll get my source code from a reputable mirror and compile it myself thanks.
Anyone quoted by a reporter knows how little they understand
Don't believe what you read is the truth.
Yes, I read it. The bug is that they write outside the end of an array.
A modern language would not catch this bug (unless you were using a data structure like a search tree instead of an array). However, it would make it NON-EXPLOITABLE, because a safe language would cause an error (ie, exception) on an out-of-bounds write, not corrupt the heap or stack and allow for an exploit.
The most important thing to realize is that when a machine is comprimised, it cannot be trusted. You may think that you were running only OpenSSH but you may have been runnning other services started a long time ago. I would be curious to know what kind of logs you had to go by to see what this attacker did. Slightly-smart ones clear every trace.
Also of note is that this particular advisory is known only to affect local users. I don't think this particular bug is the cause. It may have just been a friend shoulder-surfing.
If you want to do analysis on a cracked machine, you should place the hard disk into a different machine and examine the contents.
You don't need an interpreter to do bounds-checking on arrays. For instance, SML (that's what I wrote my ftpd in) compiles to native code and has bounds checking. There also exist native compilers for java.
It's *much harder* to make a mistake in a compiler that causes an exploitable hole in software compiled with it than it is to make the same errors over and over in the applications themselves. (Just compare the number of compiler/library-caused exploits to the number of application exploits!)
Actually, I don't care much about DOS "exploits", especially ones that require the attacker to expend resources to keep the attack up. It's pretty simple to flood my connection and make my computer unusable anyway.
In the case of SSHD, the situation you described wouldn't happen -- it spawns a new process for each connection, so an exception thrown in one wouldn't cause the others to be dropped. The attacker would merely be using up your resources.
A programmer in a modern language has plenty of choices, too. He can catch exceptions and restart the server. He can log them. And of course, the users are safe from being rooted until a patch is out.
After analysis, I can say, that this vulnerability is 4 bytes heap overflow, VERY hard to exploit. Problably only Linux will be affected, because Doug Lea's malloc() depends on control structures located just after malloced buffer.