Security Hole in SSH1 with RSAREF

Read the CERT Advisory carefully, because it's a bit complex. A buffer overrun in the RSAREF2 library, a common implementation of a common crypto algorithm, combines with a buffer overrun in version 1 of sshd to allow unauthorized execution of arbitrary code. PGP is not affected. SSH2 is not affected. All versions of the free SSH1 are affected, but only "when --with-rsaref is explicitly supplied on the command line." (On my system, "ssh&nbsp-V" tells me whether I compiled in RSAREF, presumably the same for both client and server.)

Comments

Fixing stack, or language, not good enough

[Tom Christiansen]

You make a very, very good point. Isn't there a way the Linux and *BSD kernel could be patched to disallow execution from a stack? I know there's plenty of memory protection and such in there, so can't we put in one more layer of protection?

First of all, I do believe that having everyone running a Linux kernel an i386 architecture with an executable stack is three strikes against you. The most secure sites I know are intentionally running neither that kernel nor on that chip. This introduces enough valuable diversity that it alone will stimy many script kiddies with root kits. Remember the Linux PowerPC cracking challenge? The kiddies' root kids didn't have the right machine language code to try to execute, so buffer overruns would have just DOS'd you.

So, let's just change chips. :-) Of course, that's hardly enough. Can't we clear up a lot of these exploits by fixing the stack? The answer is yes, we could clear up a lot of them. But that sadly, it's not going to cure the class of problem completely.

Why should stack and data pages be executable? Why are any pages that are executable also writable? Well, there are a couple reasons for that. Certainly it hasn't always been that way. But the signal trampoline code from gcc(1) makes this very attractive, and it's a bit annoying to change. You still have to deal with issues of mmap(2), which can ask for pages with any access bits it cares for.

And let's not pretend please that C is the issue here. It's not. You're diddling the instruction set. I don't care if you used a Pascal compiler. You could still diddle it. Then again, there's something to be said for having a cleaner library. See the end of this missive for a simple, elegant, and effective approach to one class of these problems in C by someone famously inclined toward the simple and elegant.

What I strongly suggest that anyone interested in this do is read existing literature on this. Yes, it's work, but it's really, really good for you. Start with the paper StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. And yes, the buffer overrun in the version of Perl referenced by this paper has long since been fixed. But then read about how to defeat this. You can also check out disabling an executable stack on Solaris, and why this isn't a cure-all.

Even with a non-executable stack, you can still be bitten. Several such exploits have appeared on bugtrak. Here's one. The short explanation for why this isn't a panacea is that if I push a pointer to "/bin/sh" and a (char *)0 on the stack in a place right before an system(3) (well, or or execl(3) or execve(2) or whatever) then it'll still suck to be you. Notice I haven't executed any code that I put on the stack. I just managed to change some of the arguments to existing calls.

Let me put up a copy of some mail from Ted T'so, who said it well:

Well with a non-executable stack most security conscious system administrators will sleep better :) I can guarantee that. (Not too much better as holes always exist but quite a lot).

The advantage of the patch is that it will stop the current set of attacks that take the form of "find buffer overrun in a program", followed by "apply standard toolkit to exploit buffer overrun by putting executable code on the stack".

The disadvantage of the patch is that after we apply, within a few months we will see a new toolkit of the form "corrupt the stack to point the return address into someplace entertaining in libc --- like right before an an execl call in the implementation of popen()."

The danger is people thinking that with this patch, they don't need to worry about finding and fixing buffer overrun bugs in their code....

So let's not get too self-satisfied with having non-executable stacks. It's still not enough.

Here's the promised gem of insight from Dennis:

> ..... If most implementers will ship gets() anyway,
> there's little practical effect to eliminating it from the Standard.

On the other hand, we removed it from our library about a week after the Internet worm. Of course, some couldn't afford to do that.

Dennis

That's certainly an, um, interesting approach, eh? :-)

Is this fixed already?

[rangek]

Okay, I have heard about this RSA/ssh buffer overrun thing for a few weeks now. So I do

[rangek@pinot-noir rangek]$ ssh -V
SSH Version 1.2.27 [i586-unknown-linux], protocol version 1.5.
Compiled with RSAREF.

But then I do

[rangek@pinot-noir rangek]$ rpm -q --queryformat '%{CHANGELOGTEXT}"\n"' ssh
- RSAref buffer overrun patch (rsa.c) as described in Core SDI advisory
from December 1, 1999. Thanks to Oystein Viggen for sending me this patch."

So is this the fix for the advisory in the story or is this another new problem that this package is vulnerable to?

www.zedz.net RPMS already updated

[bholzm1]

For you lazy bastards who install ssh RPMS, ssh-1.2.27-7us on www.zedz.net already has been fixed.

From the ChangeLog:

* Mon Dec 06 1999 Jan "Yenya" Kasprzak

- RSAref buffer overrun patch (rsa.c) as described in Core SDI advisory from December 1, 1999. Thanks to Oystein Viggen for sending me this patch.

OpenSSH?

[Kaa]

What about OpenSSH from OpenBSD people? Is it affected as well?

Kaa

Affected Items

[Tower]

These are the possibly affected items in the BSD family:
p5-Penguin, p5-Penguin-Easy, jp-pgp, ja-w3m-ssl, ko-pgp, pgpsendmail, pine4-ssl, premail, ParMetis, SSLtelnet, mpich, pipsecd, tund, nntpcache, p5-Gateway, p5-News-Article, ru-pgp, bjorb, keynote, OpenSSH, openssl, p5-PGP, p5-PGP-Sign, pgp, slush, ssh, sslproxy, stunnel, apache+mod_ssl, apache+ssl, lynx-ssl, w3m-ssl, zope

Not very bad

[fremen]

This is not as bad as you might think. This hole relies on ssh being built with the proprietary third party RSAREF library. If you haven't built ssh that way, then you're safe. I guarentee that 90% of the people reading this are safe. To make sure, type the following:

ssh -V

This should return the following:

Standard version. Does not use RSAREF.

Also, let's not forget that the Bugtraq people have known about this for months. If you don't read Bugtraq, you should.

Beware Of Geeks Bearing Gifts, eh?

[Effugas]

RSA's been running a rather well-rendered image of two geeks dressed up as Trojan Soldiers, with a giant hooden horse behind them. Superimposed is the text, "Beware of Geeks Bearing Gifts."

It's an ad for their upcoming RSA Security Expo, which should be absolutely fascinating to attend.

More so, now, as the down-in-the-trenches network administrators trust for them lies in quiet but definite shreds, based upon their reaction to the RSAREF2 Buffer Overflow. Buffer overflows happen. They suck, but it's a consequence of the coding systems we've just not found an acceptable replacement for. It was not their technical error but their absolutely shocking response after the hole was discovered last week:


Fix information
~~~~~~~~~~~~~~~

RSA Security was contacted and replied that they don't support RSAREF2 anymore.
For futher details you may contact John Linn

A patch is provided below, please read carefully the file license.txt from the RSAREF2 distribution before applying it.


But that's OK. It's good to know where you stand with people. The geeks of the Internet got a CERT-certified patch in. RSA made it illegal to use.

Nice. Tragic, sad, maybe even a bit pitiful. I liked RSA for a long time, and really, really expected better. Maybe someday they'll earn back my trust.

It won't be today.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com