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
Most worms scan for nt and ISS. I get like 100 a week trying to load NT files, and I'm running Apache on Linux. The hacker world would rather beat more simple targets like Windows than go for something complicated like SSH on Linux.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
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'?
Is ssh server enabled in the default install? I would think (hope) not - You don't want to run services that you do not need, and does a workstation need sshd?
SteveB.
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.
As I scan through, I see several posts of people giving up hope, and even those showing signs of dispair because they have an ssh server that they don't want to remove that service from. Fear not my friends. Simply download the rpms (openssh, openssh-askpass, openssh-clients, openssh-server) and give it an old rpm -iU openssh, openssh-askpass, openssh-clients, openssh-server It'll update everyting for you /and/ restart your services real quick.
Or, if you feel like being a man, you can compile the sucker, and copy over the older versions and restart the services manually.
Either way, there is no need to dispair. You're not going to lose your ability to serve ssh securely to your users. Of course, this comes as no news to most of you, but just wanted to explain it to the people who didn't seem to understand.
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.
Over the course of my years of slashdot reading, I have noticed that while many are quick to point out interesting tidbits on the negative aspects of OS's, Software, and Hardware. While these reviews and notes are useful, it seems that nothing is as unbiased as it might seem.
MS exploits often announced on here (yes i like to know about them) and in this case open's dev team mistakes are also what I consider news, however I cannot remember the last time anybody pointed out the dangers of RedHat. While every new version of a linux distro is waved about with great expectations and cheer, other OS's are actually being analyzed for the bad as well as the good. I won't say that nobody posts unbiased articles, and I will even admit that if every stupid needless redhat exploit were listed on slashdot, RedHat would look as bad as Windows. Almost every OS and piece of network software has exploits, and very VERY few developers ever get it right the first time. I just wonder why it's so easy to see all of the mistakes for software that we may not (choose/want to) use while pretending all those dozens of RedHat exploits we had to patch never really were a problem.
Those who even bothered to reply to this newsworthy post with openbsd-bashing, are the ignorant monkeys of the open source community and have obviously never really compared UNIX's in the server world.
Those who bothered to reply to this stating that C is the wrong language to code in bring up minor points and expect the code that drives the internet to change. C is small cpu load and if it turns out buggy, it is the developers fault. But to expect software developers who write based upon existing libraries and code concepts they have developed over decades of work to stop and try writing their apps in an experimental (and YES, pretty damn potentially exploitable itself being so new) language is just silly. PHP is "a modern language" and was just recently found exploitable despite years of development in the PHP arena. IMAGINE the chaos if the development language that your OS/net apps were written in was found to be buggy? To date I have not had to download a new version of gcc and recompile my OS/kern/3rd party apps due to a "C vulnerability". Using experimental non-prooven ( 10 years?) languages for OS/kern/apps is a pretty stupid risk.
As an OpenBSD serveradmin running a number of co-located webservers, I can offer this advice:
v &m =101473993002531&w=2
Do not install OpenSSH 3.1 over OpenBSD 2.8 unless you desire intense pain, punishment, or peril.
I tried this, and immediately ran into error messages since my OpenSSL library was out of date. (OpenBSD 2.8 ships with OpenSSL 0.9.5a by default) Once I got a new version of OpenSSL built and installed, I tried to compile OpenSSH 3.1 again, but the end result would not allow password interactive logins for some odd reason. I spent a few hours working on this issue, which put some of my paying customers in a tough position as they were unable to access the server through SSH.
I finally gave up on the 3.1 release, and found the security patch for OpenSSH 3.0.2 issued by the kind folks at pine.nl (thank you!), which, when recompiled, worked flawlessly.
The only clue that I had as to the OpenSSL library version dependency was one short, obscure mail message on the openssl-unix-dev mailing list, at this URL:
http://marc.theaimsgroup.com/?l=openssh-unix-de
This is another example of some of the frustrating aspects of OpenBSD and the way it is maintained. This OS is well-written in general, but the documentation and help text for server admins is quite lacking. Nowhere on the OpenSSH webpage was there any mention of a version incompatibility with OpenBSD 2.8's default OpenSSL installation. Nowhere on the OpenBSD pages is there a quick, easy, simple set of steps that one can take to update just one's local source tree to the current version of OpenSSL as approved by the OpenBSD team.
(Yes, I know there are man-pages for CVS. I don't care to take the time to learn the entire set of command-line options, and in situations like this, it is far more useful to get clear, simple and relevant instructions for how to fix the latest hole before some script kiddie beats me to the punch and "0wnz" my server.)
I would also caution Slashdot readers not to automatically assume that OpenBSD is "secure by default" just because the development team says so. Smart server administrators will quickly realize that a number of things need to be closed up after the default install. However, this is still *BY FAR* more secure than other OS's, which is why I will continue to run OpenBSD. For now.
Regards,
support at doughmein dot net
Super ninja monkeys will one day rule the world!