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."

Comments

Re:Full disclosure = annoying.

[SquierStrat]

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.

Re:linux patch available

[MrDingDong]

Its out there - at least on ftp.openssh.com. I built and installed 3.1p1 a couple of hours ago on Linux.

Correction: off-by-one

[MarkusQ]

Seems as though its a one-off error

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

Re:There goes OpenBSDs slogan...

[Chundra]

Ummmm, RTFP!

They aren't ruling out the possibility of a remote exploit.

Re:More Proof

[SquierStrat]

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.

OpenSSH site already updated?

[Noryungi]

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.

Re:OpenSSH site already updated?

[BlowCat]

Good thing that it's not a remote root exploit. Otherwise www.openbsd.org would now read:

Four days without a remote hole in the default install!

Not sure if OpenSSH is enabled by default though.

Re:OpenSSH site already updated?

[sheetsda]

OK, I'll bite.

The OpenSSH people corrected the bug in their own source, which they would have had access to even if it was closed.

Sure, if they found out about it before a blackhat did. There's a good chance they wouldn't have. And anyone could've corrected the issue and submitted a patch; in OSS there may be a patch before the public even knows there was a vulnerability.

The vendor was notified ahead of time, which is one of the things that MS has been campaigning for. Why aren't we beating up on the guy who released this to the vendor first and not to the community immediately?

There's a policy among bug reporters to give the author a reasonable period of time to fix a bug before releasing it. MS gets that grace period about as often as everyone else, but they're so slow at getting out patches that the vulnerability runs rampant. If an OSS project is slow at getting patches out, someone else takes it upon his or herself to write a patch. Its sort of a self-correcting system.

smallest possible patch

[bill_mcgonigle]

For you guys too lazy to read:
http://www.pine.nl/advisories/pine-cert-20020301.t xt
( 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?

I can't wait for djbssh

[Russ Nelson]

I can't wait for the Daniel J. Bernstein version of ssh.
-russ

Re:I can't wait for djbssh

[Anonymous Coward]

you mean the one that requires you to set up 3 accounts for the client, 3 accounts for the server, and comes with its own inetd replacement?

Re:I can't wait for djbssh

[biot]

It would be incompatible with the rest of the world's ssh implementations, of course, but I guess he'd write a DJB-RFC to take care of that.

Re:Full disclosure = annoying.

[Sarin]

Nah they don't.;) But I'm working on exploit code as we speak.

Please stop writing network apps in C!

[Tom7]

This kind of bug would NOT BE EXPLOITABLE if sshd was written in a modern safe language.

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=2629 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.

I'm trying to raise awareness about this because I think it's a real obstacle to us having secure software.

Re:Please stop writing network apps in C!

[MartinG]

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" ??

Re:Please stop writing network apps in C!

[coyul]

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'?

Re:Please stop writing network apps in C!

[abaptist]

If you look further down in the patch, it then references an array with offset 'id'. In a language like Java this would throw an ArrayIndexOutOfBounds exception, NOT read random memory and possibly cause a crash.

So in fact a stricter language would fix this problem.

Re:Please stop writing network apps in C!

[Tom7]

> 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?

I can't handle 18,000 simultaneous connections, but I don't think that 99% of people actually care about that. In fact, I don't think linux even supports 18,000 open file descriptors at the same time. My ftpd is intended for the home user who cares more about getting rooted than the low-level performance of his servers.

Yes, it uses sendfile to transfer files when it doesn't need to do EOL conversion. I'm easily able to fill my 100Mbps connection without breaking a sweat either way. (In my informal benchmarks, my server got exactly the same transfer rates as wu_ftpd).

> 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"

Well, ok, but what would be a good reason to?
One might be that you need to write a server that can really handle 18,000 connections. (Then, I hope that the users of your server have enough cash to pay someone to maintain them, apply security patches, etc.)

> 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.

Yes, that's true. SSHD probably uses much more CPU than a typical network app. Yet (see my other posts), it really doesn't use that much anyway.

I wouldn't suggest writing it in perl, since perl has its own kinds of easily exploitable bugs. Also, the performance of perl is not in the 20%-100% category that I mentioned. ;)

> BTW, out of interest, what is your "favorite
> modern language" ??

Standard ML. It's got loads of cool features like higher-order functions, polymorphism, datatypes, parameterized modules, and static typing (which also really helps to catch bugs). It's natively compiled and quite fast. You can learn about it at standardml.org. Hacker types might like O'Caml better, that's at caml.inria.fr.

OpenBSD upgrade.

[saintlupus]

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

FreeBSD affected; patches available

[Dom2]

Unfortunately, I can't post the advisory here due to the lame lameness filter. But here are the patches:

ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/S A- 02:13/openssh.patch
ftp://ftp.FreeBSD.org/pub/Fre eBSD/CERT/patches/SA- 02:13/openssh.patch.asc

Execute the following commands as root:

# cd /usr/src
# patch < /path/to/sshd.patch
# cd /usr/src/secure/lib/libssh
# make depend && make all
# cd /usr/src/secure/usr.sbin/sshd
# make depend && make all install
# cd /usr/src/secure/usr.bin/ssh
# 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+0 +c urrent/freebsd-announce

Visual Basic

[wiredog]

Has all the features any Modern Programmer could want. And it has the Highly Secure .net framework built in. What more could you want?

Isn't this a bit dodgey?

[SomethingOrOther]

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.

Performance of network software

[Tom7]

> 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, of course I read the patch.

[Tom7]

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.

FYI: my box may have been exploited by this

[umoto]

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".

Re:*** Help on upgrading a remote server?

[Bluecoat93]

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.

Exploiting scenario

[pmf]

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.