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."
This is just more proof that nothing is 100% secure. :-) How does that saying go, if it can be devise it what? Some want to finish that for me?
Regardless of that though, I get on my knees and thank God everyday for SSH. It's saved me many many many hassles from simply forgetting to turn it off on computers on my home's network.
Derek Greene
Ummm, RTFP!
It's a LOCAL exploit. You have to be logged in to exploit it.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
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
Its out there - at least on ftp.openssh.com. I built and installed 3.1p1 a couple of hours ago on Linux.
One-off: Something done intentionally but with no intention of repeating; a custom product, sample, or prototype.
Off-by-one error: An error in enumeration, such as starting or ending a count at the wrong value (e.g. 0 vs. 1), counting the starting/ending value in a cycle twice or not at all (e.g. in counting a group of people which includes yourself), counting delimiters as opposed to the items delimited (e.g. the "fence post" problem), or any analogous error.
These are rather different! When I read the abstract my first thought was "how can they determine that?"
-- MarkusQ
Ummmm, RTFP!
They aren't ruling out the possibility of a remote exploit.
Here is what can be found on their web site:
"OpenSSH 3.1 released March 7, 2002."
Hmmm... That was quick! Especially since the advisory reads:
Pine Internet Security Advisory
Advisory ID : PINE-CERT-20020301
Authors : Joost Pol
Issue date : 2002-03-07
Application : OpenSSH
Version(s) : All versions between 2.0 and 3.0.2
Pretty good job.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
For you guys too lazy to read:t xt
http://www.pine.nl/advisories/pine-cert-20020301.
( I was going to post the patch here, it's really small, but apparently slashcode doesn't know what the blockquote tag is for, despite claiming it's supported)
But this isn't just an attempt at karma whoring, there is a point. When a single missing '=' can cause a root exploit in code that's generally considered well-written, who are these people that actually entertain the idea that Microsoft secured their software over the last month?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I can't wait for the Daniel J. Bernstein version of ssh.
-russ
Don't piss off The Angry Economist
Looks like it is already availble in tarball and RH72 RPM format.
Nah they don't.;) But I'm working on exploit code as we speak.
This kind of bug would NOT BE EXPLOITABLE if sshd was written in a modern safe language.
9 013 for more info. Synopsis: There are some reasons to use C for a project, but none apply to network daemons. As a proof of concept, I rewrote FTPD in my favorite modern language; the source went from 24,000 lines to 3000 (including support code, like PAM_MD5 password encryption), took me only a weekend to write, and is 100% buffer overflow / format string / heap corruption free.
If the canonical secure software from the canonical secure software people has bugs like this, I don't see how anyone can argue that it's possible to write secure code in C. C makes it easy to make this kind of bug, and the bugs are often exploitable.
Check out my previous post and ensuing discussion on this http://slashdot.org/comments.pl?sid=24271&cid=262
I'm trying to raise awareness about this because I think it's a real obstacle to us having secure software.
Now this is public knowledge, an exploit will be available within hours.
You do not know what you are talking about. Full disclosure has greatly improved security awareness and turn around time for fixes. If you want to turn your back on full disclosure, you are heading back into the middle-ages of computer security.
This should have been fixed before it was announced, and a period of time waited for people to upgrade.
The information was leaked by someone who jumped the gun. That is the reason why the relase and advisory happened today instead of Monday. Nothing to be done about it. Instead of bitching, fix a bug in your operating system and send a patch to the developers. Much more useful behaviour for all of us.
Of course, you should be running with ln -s AJ /etc/malloc.conf
anyway. It will fill freed memory with junk,
and quite often finds conditions where memory
is referenced after it has been freed.
In that case, there is no problem anyway. If your operating system of choice has not support for malloc debugging, looby
your developers, it is a very useful feature.
OpenSSH 3.1 was released this morning. The info and tarball for OpenBSD systems is available at:
http://www.openssh.com/openbsd.html
Mine's compiling now.
--saint
Unfortunately, I can't post the advisory here due to the lame lameness filter. But here are the patches:
S A- 02:13/openssh.patche eBSD/CERT/patches/SA- 02:13/openssh.patch.asc
/usr/src /path/to/sshd.patch /usr/src/secure/lib/libssh /usr/src/secure/usr.sbin/sshd /usr/src/secure/usr.bin/ssh
0 +c urrent/freebsd-announce
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ftp.FreeBSD.org/pub/Fr
Execute the following commands as root:
# cd
# patch <
# cd
# make depend && make all
# cd
# make depend && make all install
# cd
# make depend && make all install
If you've got the ssh port installed, check out the advisory for details on what to do:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+
Has all the features any Modern Programmer could want. And it has the Highly Secure .net framework built in. What more could you want?
Best Slashdot Co
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.
> I cry BS. Your previous post claimed that
> performance was not a reason and yet I don't
> believe you. Wake up and stop acting as the HW
> vendors lobbyist.
Actually, I am a "modern languages" lobbyist, not hardware. =) But that's because I study and believe in programming languages, not because I have some kind of financial interest.
I'd love to respond to your post but I don't know what your point is. I guess all I can do is reiterate my point on performance:
1. sshd, running on my machine for about 8 months, has accumulated a mere 2 minutes and 30 seconds of CPU time. Of course, sshd forks off a new process for each connection, but all of the ones on my machine (some of which are at least a week old) have used 0:00. If someone knows a way I can measure the actual time spent by the daemon, I'd like to hear it, but I assume for now that it is *very small*.
2. I can easily fill my 100Mbps connection without breaking 2% CPU usage. (In other words, sshd is bandwidth limited, not CPU limited.)
3. Most home / small business users do not have 100Mbps connections, and could care less about the difference between 2% or 5% CPU usage.
4. However, most home / small business users DO care about having to download patches when their C programs contain buffer overflows.
5. Modern languages are not actually much slower than C. (I estimate worst case 2x slower, typically more like 20% for SML, which is what I wrote my FTPD in.) Being easier to write in, they also give more opportunity for high-level optimizations.
Therefore, I conclude that for almost every user, security is a more important concern than speed, at least as far as network daemons go. How can you argue the opposite?
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.
Two weeks ago my Mandrake box, connected to a cable modem, was rooted. The only port open to eth0 was ssh (openssh-3.0.2p1). I analyzed the logs and they indicated someone had spent an hour trying to exploit various SSH bugs that have been fixed in the past. Then there was an 8 minute pause before "linsniffer" was installed and eth0 went into "promiscuous mode".
I haven't been able to verify openssh-3.0.2p1 was truly the cause, but it seems likely. This may have been the remote root exploit which the advisory "does not rule out".
Known to work on Solaris, OpenBSD, and Linux. YMMV elsewhere, but it should work fine.
1) Use SSH to log into your server.
2) Install the new ssh version. Your old version is in memory, so replacing the binary won't have any adverse effect on your connection.
3) Run 'ps -ef | grep sshd' or 'ps auxw | grep sshd' (depending on your UNIX flavor)
4) find the sshd instance with a parent process ID of '1' -- this will be the actual daemon spawend by init. The other process will be the one spawned by sshd itself to handle your connection.
5) kill
6) the parent sshd process will terminate, but yours will stay running
7) start up the new sshd
8) from another workstation or window telnet to port 22 on your server and verify that the version number reflects the new version.
9) from another workstatino or window, ssh into your server to make sure you still have access.
10) close your original ssh session
I've used this exact process to upgrade many machines at remote locations. As long as you verify that the new sshd is running before you close your existing connection, you should have no problems.
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.
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.
If there were such a thing, it would use ucspi-tcp, not an additional inetd replacement, and like qmail. Ucspi-tcp provides functionality that inetd doesn't, and maintains the "connection handling" vs "services" separation that inetd provides. It is a natural step to replace parts which do not provide whatever is needed, and to reuse those parts.
Also, qmail's division of the jobs into multiple independant modules makes security analysis and improvement of the whole package much easier. Every module is completely and explicitly documented in man pages and numerous web pages, so even a less advanced programmer like me can write a wrapper for a module to add funcionality to. The risk of unexpected consequences is FAR lower because modules have their own UIDs.
If there's a good reason for it, why not do it?
Don't bet on it. A while back, for kicks, I checked to see who was bombarding what ports on my box with attempted hacks. A large portion of them came from 0wn3d Linux systems. I'm just glad that (a) I kept things patched (b) didn't have a default RedHat install and (c) had a MIPS processor that obfuscated any hole I didn't yet know about.
If you don't patch a potentially remote-root hole, it's not a case of "if". It's a case of "when" you'll be 0wn3d.
Oolite: Elite-like game. For Mac, Linux and Windows
Did you build the *portable* version (not the *BSD version?)
The portable version built cleanly and ran on both my Intel-based Linux system and my ancient MIPS-based Linux system. The *BSD version will not compile on Linux. Make sure you have the right version!
Oolite: Elite-like game. For Mac, Linux and Windows