Slashdot Mirror
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 -V" tells me whether I compiled in RSAREF, presumably the same for both client and server.)
Someone on BUGTRAQ floated that the RSAREF buffer overflow might be used in an AIM-style ``detection'' fashion. (Remember the AIM buffer overflow that was used to see if the client on the other end was a ``genuine'' AIM client or not?)
As most know, if you're in the US, RSAREF is the be-all and end-all of what you can use -- and only then, noncommercially. If you want to use RSA without RSAREF, you have to buy software from someone who pays RSA licensing fees. (On a side note, it's probably worthless to see if you can get a personal license from RSA to use OpenSSL or some other toolkit, even if you have money. I floated this question on the OpenBSD list, since OpenBSD includes OpenSSL, and it seems it's been tried -- and RSA ignored the request.)
In any event, RSA could theoretically use the RSAREF vulnerability to scan US hosts for compliance with the RSAREF mandate. If the buffer overflow was there, and they were a commercial entity, the red alert klaxon would sound and the lawyers would be summoned. Not a pretty picture.
The way to combat a potential scenario like this would be to get the news out as fast as possible that you can patch RSAREF (RSA graciously allowed us in the CERT advisory to patch it, gee how nice of them) and should ASAP.
And to RSA as well. It's amazing to me that in the CERT advisory, they grant permission to have this fix be made, but don't grant permission for any further fixes to be made, should they become necessary. I can see if, in their original onerous license, they might not have added that clause just because they weren't thinking about it. But come on, RSA! Wake up!
My personal feeling is that they put out the code ``for the benefit of academia'', to train a horde of students to bow down at the RSA throne -- and then when those students get out in the Real World(TM), they love RSA the algorithm, but need to shell out big bucks to use a better RSA implementation because -REF just plain sucks. It would not surprise me if this were intentional.
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:
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:
That's certainly an, um, interesting approach, eh?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?
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.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
SSH 2 is not affected... though it certainly had its share of problems earlier, but it *seems* as if most of those have beentaken care of.
Not to mention that you have to specifically enable this particualar library - which I doubt most people would have, given the other choices of ciphers (correct me if I'm wrong, but *I* saw no reason to)... then again, IANACG (Crypto Guru)
"It's tough to be bilingual when you get hit in the head."
What about OpenSSH from OpenBSD people? Is it affected as well?
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
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
"It's tough to be bilingual when you get hit in the head."
This is a classic example of ``security by obscurity'', and it's what Microsoft relies on. I would say that the problem would have been found eventually. If you follow BUGTRAQ at all you'll notice that there are people finding buffer overflows in code they don't have the source to simply by throwing shellcode into fields that look like they have a fixed length. If it makes it crash, they've found a potential exploit. (Note to security gurus: yes, I know this is terribly simplistic; but it makes my point.)
RSAREF is provided as a service to people who want to do R&D and have more brains than money, as it were. Datafellows Ltd. and the other windoze SSH vendors had to license BSAFE or negotiate their own license for implementing and selling RSA-capable software in the USA for money, as is the intent of RSADSI (it is their livelihood).
Nonetheless, for non-commercial usage, there are more than a few people who might suggest that it is worthwhile to sidestep this issue by simultaneously not depriving RSADSI of income, and also not leaning on them to support RSAREF, which sucks and is a total waste of time/money for them. I'm not saying that you should do an end run around the patent if you live in the USA. What I am suggesting is that
So, make up your own mind about what's morally, legally, and ethically the right thing to do. Our patent system sucks, the "Smart card" RSA patent may not really apply, yada yada, but more importantly, what is the Right Thing to do here?
I can't make that decision for you. All I can do is present the facts and some relevant discussion.
If you want more explicit advice, you can ask RSADSI, but they are famous for being vague about these issues, and aren't making any money by supporting stupid questions about free libraries.
Remember that what's inside of you doesn't matter because nobody can see it.
Just a quick note, if you got your SSH from Replay.com (which provides Red Hat packages), and got the US version, you're using RSAREF. If you got the Debian package, you're not. I'm not sure if Replay.com has updated their RPMs or not, though.
:)
For me, that means the machines at work were vulnerable, and the machines at home are not
--Matthew
I believe that the comment was very informative; if you followed the link to the CERT advisory he gave.
If you don't like people who answer with links, that's fine. That has nothing to do with moderation in most cases, and in this case, nothing at all because you weren't the one with the moderator points.
- Michael T. Babcock (Yes, I blog)
guarentee that 90% of the people reading this are safe.
I think you are wrong. A lot of people install ssh from the ssh rpms available on rpmfind. The us versions here are compiled with RSAREF. But I think the latest version fixes this. See my other post.
This is what I get:
clf:~> ssh -V
ssh: SSH Version 2.0.13
I'm ok, right?
Doh.
clf:~> ssh1 -V
SSH Version 1.2.27 [i586-unknown-linux], protocol version 1.5.
Standard version. Does not use RSAREF.
is more useful.
sorry.
I shoulda been installing SSH via sources anyway.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
If you get hacked because of this bug, please write a nice "thank you" letter to the U.S. Patent Office.
RSAREF is also slow. I think RSA believes their patent enforced monopoly entitles them to write sloppy, slow, poor quality code. The international RSA libraries are much better all around. Not that I would encourage those of you in the US to violate the law by avoiding RSAREF...
But I would like to point out that the RSA patent is about to expire, and those of us in Canada and Europe don't touch RSAREF with a 10 foot pole.
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.
Isn't this what caused the demise of RootShell?
I remember reading an explanation of a buffer overflow in ssh that allowed a cracker to get in to the last server anyone would have suspected a successful breakin to...
OFTC: By the community, for the community
Why is it a "problem" that he uses packages? So it turns out the bug was fixed on his system BEFORE HE EVEN KNEW ABOUT IT. I'd say that was one major point to the "I use binary packages" team, not the other way around.
No offense, but not all of us have time to wade through security issues at the end of every day, download source code patches and recompile our affected apps. (Though don't get me wrong, I do spend a very insignificant portion of my work day browsing Bugtraq e-mails.) Bug reports like this tend to be very well researched and include information such as affected packages and affected stock distributions.
Major package distributions have people on staff that do this for us, update packages, and ship out updates in very short order. In this case, the patch was made available very shortly after the bug was announced to Bugtraq, and new RPM's were made available shortly after that. If you don't trust your vendor to be on the ball with things like this, it's time you found another vendor.
For those administering high-profile systems, systems in a high-security environment, or packet kiddies that just KNOW they're going to be hit by their IRC "enemies" as soon as any exploit is released, definitely either stick with source releases and apply patches immediately, or pay attention to ways to work around problems until an official/binary patch is made available.
For The Rest Of Us, RPM's and packages are much less of a headache (mine are downloaded and installed automatically), and I can spend my free time USING the tools on my system instead of being "elitest" and re-building them all the time.
Its interesting to see all the discussions on slashdot about this set of vulnerabilities and the CERT Advisory. I'll try to answer some of the questions raised here.
1) What was the delay?
We try very hard to be as "correct" as possible when writing an advisory, and to put the problem in the proper scope, which sometimes means we're slower than other sources, but also usually means that we are generally pretty accurate. The original ssh vulnerability was not directly exploitable, but the CORE SDI folks found the RSAREF vul, which can be exploited through the ssh vul. In working with them, we understood the problem, and began to contact vendors who might be affected. We then discovered that the original fix as provided by CORE SDI wasn't complete, and worked with them to develop a more complete fix. Also, there were a wide variety of legal issues to discuss with our legal counsel. It takes a while to get all the ducks in a row. By far, though, the biggest chunk of time was trying to understand the whole scope of the problem -- what products might be affected, etc.
In my experience, most compromises happen well after the fix has been known for a long time anyway, so I believe that a delay to make sure we've got the facts straight is usually better than being the first one to get it wrong.
Having said that, though, I believe it is crucial for sites concerned with security to monitor sources like BugTraq and Security Focus. We don't pretend to be a replacement for sources like that.
2) What about product X?
If we have information about a particular product, its in the advisory.
3)Is CERT trying "to act like international users are not affected?"
I don't think anything in the Advisory implies that international users are not affected. We do say "sites not restricted by patent law may choose to use a non-vulnerable implementation of RSA." But that's not the same thing.
If you have other questions not addressed in the Advisory, or suggestions, comments, or criticisms about the advisories in general, you can mail them to cert@cert.org> . I'll do my best to personally respond, modulo the slashdot effect. :-)
Shawn Hernan,
Vulnerablity Handling Team Leader,
CERT/CC
I thought it was safe reading the message you posted, however someone followed up with this:
---------------------------
Date: Mon, 13 Dec 1999 22:03:15 -0300
From: Iván Arce
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Re: ssh-1.2.27 exploit
snip
We have a working exploit against Linux and OpenBSD, we are waiting for CERT to publish their advisory. As soon as that happens, or before if its taking too long, we'll publish the exploit. Since the problem is not being actively exploited (as far as we know), there didnt seem to be a reason to post the exploit code with our advisory.
-ivan
---------------------------
In the US, your RSA implementation *must* be licensed from RSADSI. This means either using a product from a commercial vendor that has licensed RSADSI's commercial-grade RSA implementation, or, if you're a non-commercial entity (or a commercial entity not using this in a commercial capacity [such as a secure Intranet site, I believe]), using the "public" (crappy) RSAREF library.
As the RSA algorithms are patented only in the US, it's illegal to use any other RSA implementation not specifically licensed from RSADSI. Outside of the US, the patent does not apply and you're free to use better, open RSA implementations.
Because it's illegal in the US. RSA implementions used in the US must be licensed from RSADSI.
Once September rolls around, the patent will end and the US can finally move to better RSA implementations.
The idea of a non-executing stack has been tossed around for ages. The problem with this is that it would break programs that use dynamic executable code. I believe Perl, for example, would be unusable on such a system.
I think I've also read someplace that i386 architecture does not distinguish between executable pages and text pages in memory. You can mark a page read-only, but you can't mark it unexecutable.
My memory may be mangling my recollection of these issues, so feel free to correct me if I'm wrong.
So long as your RPM files are up to date, you're fine. I believe Red Hat released updated RPM's quite a long time ago that addressed this vulnerability.
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
Perhaps you're thinking of Franz Lisp.
Even if the 386 had no support for separate rwx bits on page tables, there are newer architectures available.
But that won't help you, really. I'll explain why in a separate posting.
According to ssh.org:
l _licensing.html
You can get the SSH2 from various anonymous ftp sites around the globe for purposes of NON-COMMERCIAL USE and EDUCATIONAL USE as defined by the Licence Agreement.
http://www.ssh.org/licensing/ssh2_non-commercia
So it all depends on what position you are in. Works great for me(tm)
"It's tough to be bilingual when you get hit in the head."