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

More Proof

[SquierStrat]

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.

Re:More Proof

[Anonymous Coward]

Does it bother anyone else that the last THREE releases of OpenSSH were because of discovered holes? Not very encouraging from a group of induhviduals who like to pride themselves (and very loudly at that) on security.

Re:There goes OpenBSDs slogan...

[SonicBurst]

Actually, they may have to backdate that slogan. The problem has existed since version 2.0, so this hole would have existed since whenever they started shipping with at least version 2.0. And by the way, it is local exploit as of yet, however, remote exploitation has not been ruled out.

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!

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

Re:Please stop writing network apps in C!

[Tom7]

AC Writes,

> So it still comes back to "don't do it if you
> don't understand the problems"? It is conceivable
> that someone could code a library poorly and cause
> a security problem, but according to you it rarely
> happens. This just leads me to believe that it IS
> okay if you know what you're doing. What you mean > to say is that one should use a more recent
> babysitting language if they're not capable of
> doing it without having their hands held.

Yes, in a sense. Here's how I would say it, though: we want to minimize the amount of trusted code. To a certain extent we need to trust the OS kernel, the compiler, and some libraries (depending on what language they're written in). That's because everybody makes mistakes, even smart people who know all about good C coding (like the OpenBSD/openssh people), and mistakes in C are often disastrous. Even people who are really good at C should avoid using C whenever possible, because it increases that trusted code base.

Actually, my group at CMU is working on trustless compilers (that is, compilers that produce checkable certificites that they did a good job). I'll be back in a few years talking about how this technology can reduce the (already few) security concerns with using a compiler. But for now, the biggest step is to keep people from increasing the size of the trusted code by writing applications in low level languages like C!

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?

Or use Kerberos

[fw3]

Kerberos developed at MIT and used in many (most?) large-scale production systems. Source available.

Kerberos has been around since '88, opensource (MIT license). It is not developed at the breakneck pace of the more modern SSH and to my knowlege has had fewer exploit bugs in 14 years than the assembled flavors of (commercial *&* open) SSH have exhibited in the last 2 years.

Krb5 is not slick as SSH, you can't use it for a poor-man's VPN; it uses a more expensive cypher (3DES) for both auth and fully encyphered network connections. Rsh, rlogin rcp all available with strong encryption. It's not as easy to setup, nor well suited to very small networks but for my money where applicable it's a far more solid solution.

And yeah OpenSSH's seriously checkered security record has done very little to make me think of applying OpenBSD .. thoughts?

MacOS X

[jjeffrey]

MacOS X 10.1.3 (latest version as of now) includes OpenSSH 3.0.2p1. I wonder how long before Apple get a patch out... I don't really want to rebuild from source on MacOS X, even though it did only take 5mins to build 3.1p1 on my FreeBSD firewall.

Ha ha, ignorance is funny.

[Crag]

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?

Re:I don't think so.

[Alioth]

The hacker world would rather beat more simple targets like Windows than go for something complicated like SSH on Linux.

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.

Re:Exploiting scenario

[pmf]

Each user has it's own fork()ed copy of sshd running, so overflow can occur only in your own copy of sshd. The ONLY way to exploit it is to fool glibc free() by overwriting fd->prev or fd->next pointer.