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.)
The question I replied to would not have arisen if the original poster had read the advisory before posting. So I don't understand what's wrong with telling him to do just that.
EagerEyes.org: Visualization and Visual Communication
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.
The last time I reported an overflow vulnerability in the NT kernel to Microsoft, their bug-report CGI script crashed and the bug report was lost. Very frustrating. So, for the record, here it is.
There's an exploitable bug in the decompression code for RLE-compressed BMP files. (Yes, that code is inside the NT 4 kernel. Bad design decision.) It's easy to create a BMP file that will crash NT 4 every time it is opened. An attack could potentially be built on that, with enough work.
I don't really have the time to analyze this problem in detail, (life is too short to debug other people's code without source) but someone might want to work on it and report it to CERT.
I just installed the new package, but when I do an ssh -V I still get the message:
$ ssh -V
SSH Version 1.2.27 [i586-unknown-linux], protocol version 1.5.
Compiled with RSAREF.
What gives? I thought RSAREF shouldn't be there anymore.
If you're going to fake a high score, try making it look right next time...
> There are some Solarises ..
> shouldn't it be Solorides?
"Solarii"
Did you even bother reading the other posts? A few other posters also noticed that the "answers weren't helpful"
when someone is asking for a simple yes/no answer, and you're making them go click on the hyperlink when you could've answer their question in less keystrokes, that sounds pretty rude to me.
Capiche?
big faggots like you usually hate the little faggots.
Visit http://www.lysator.liu.se/~jon asw/freeware/niftyssh/ for the info and download.
So here's a question: If RSAREF is SOOO bad, and you need to use it in the US for patent reasons....
Is there any reason why we couldn't gut, clean and all but replace the code in RSAREF, document the changes and still stay within the bounds of the license??
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?I've said this before. I'll say it again. How the fuck is it that replying to an offtopic post is itself an offtopic act? Go moderate the person who actually started down the path of diversion. But don't go fucking jamming on somebody who gives real information about the post he's replying to just because seven levels ago the topic was different and because you happen to recognize the name of the deeply nested poster. Fucking moderator bullshit.
Given that they're an IP-happy organization with a long history of iffy code I'm glad to see that they're doing the obvious thing and giving others permission to fix the problem. Of course if they weren't requiring use of their code for "their" algorithms this wouldn't be an issue.
Actually, if I'm not mistaken, RSAREF is open source, in the case that the RSAREF license allows you to patch the library to make it run faster. If it's closed-source, you wouldn't be able to do so, and there would be no point in having such a clause in the license for it.
Dogma: Dead (mostly because your Karma ran it over)
It's interesting that the CERT advisory was dated yesterday.. I saw a notice a couple weeks ago here, unless this is another RSAREF2 issue. If it is the same, I'm curious what the delay was for, does CERT do its own research/checking on matters before releasing advisories, or did it simply take awhile for word to spread?
What are you, some kind of empath? You can tell from where you sit that the guy was snapping at the other poster? When I look at it I see that guy is trying to be helpful by pointing him to the link that has the answer to the guy's question.
It's uptight people like you who make me sick. Someone should moderate you down.
I fully understand that I will be moderated down too.
Hates people who have stupid little sigs
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?
anyone know if ssh works with linux?
Happily undiscovered by whom? If the wrong person happened to stumble across the bug and didn't say anything they could cause all sorts of havoc.
"as plurdled gabbleblotchits on a lurgid bee" - Prostetnic Vogon Jeltz. (One man's humorous is another mans flamebait)
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.
Hey does that thing require a windows machine to run? If not, maybe I'll try it out. My employer is a cheap-ass mofo, so a $0.50/hr pay raise would be a huge bonus for me.
Suggested rating -- (Score: -2, crackhead)
Try this, Tom. Never respond to an offtopic post, especially an anonymous. The original will get ignored by the moderators, or blessed, but you'll get blasted. Some kiddies get their rocks off of zapping people with known names, and ignore worse abused. Get used to it.
Metamoderator says: Offtopic.
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."
Metamoderator says: flamebait.
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.
Metamoderator says: offtopic
Anyone who ever asks you why open source software has an advantage point them to this story. I'm willing to bet if only the binaries for the ssh protocol were sent this still would not be a known problem. Thanks to whomever took the time to find this security hole!
"as plurdled gabbleblotchits on a lurgid bee" - Prostetnic Vogon Jeltz. (One man's humorous is another mans flamebait)
Beat the scripts and script kiddies
Metamoderator says: this is so offtopic
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."
metamoderator says: offtopic and overrated
Microsoft The Microsoft Security Response Team has investigated this issue, and no Microsoft products are affected by the vulnerability
ssh isn't the only application that uses RSAREF. This is NOT a problem with the sshd source, it is a problem with the RSAREF source! From the OpenSSH advisory: - openssh: Even though the OpenSSH code checks all input parameters carefully, internal RSAREF functions can still overflow. Users within the USA should update their shared ssl library. - isakmpd: When used with x509 certificates and rsa signature mode, the signature functions in RSAREF might overflow. - httpd: When SSL support is enabled in /etc/rc.conf using -DSSL, and when using RSA keys, the signature functions in RSAREF might overflow. -Brock Tellier
Ehh, some of us in the US don't touch RSAREF with a 10 foot long pole.. or even a 100 foot long pole for that matter.
Dogma: Dead (mostly because your Karma ran it over)
For what it's worth, I'm using the Debian version of ssh, installed from ssh 1.2.26-1.2 out of stable, and ssh -V reports:
SSH Version 1.2.26 [i586-unknown-linux], protocol version 1.5.
Standard version. Does not use RSAREF.
So all of you with a stock Debian slink install should be okay. Does anyone know about the ssh version in potato (unstable)?
Sean
metamoderator says: this is TERRIBLE flamebait. why isn't the parent marked way down?
metamoderator says that metadiscussion is offtopic
Sorry for the long post and resposting without permission, but it seemed relevant...
First reply to the "Metamoderator says: this is so offtopic" message!
Non-commercial users, as I understand it, must also use RSAREF and aren't allowed to go with faster, better alternatives.
If RSA had found this problem before anybody else, scanning commercial entities to see if they were using the non-commercial-only RSAREF is only the half of it. They could also have scanned non- commercial entities to see if they were using non-RSAREF libraries. Patent violations! Cease And Desist! Kill! Kill! Kill!
I installed ssh from RPM files. ssh -V tells me the client does not use RSAREF. The advisory does not say how to test the server.
/etc/ssh/sshd_config file:
These lines are in my
RhostsRSAAuthentication yes
RSAAuthentication yes
Is RSAREF the same as RSAAuthentication?
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.
You already have a right to patch. Check out 17 USC 117.
Anomalous Cowherd
If your car were an old beat-up rusted-out Pinto that didn't start, chances are pretty good that nobody would steal it. That's the case here. The RSAREF library is generally considered far inferior to the international libraries, and nobody in their right mind outside the US would consider using it, all legal issues aside.
\\'
Could some kind soul please explain...
1) What is RSAREF?
1a) Is RSAREF only required if you use the RSA encription algorithm?
1b) Can one use ssh (or OpenSSH) without RSA? Is this preferable?
2) Is it legal to use ssh without REFRSA in the US?
Thanks
Too bad you can't use Blowfish with SSH... Without RSA, how will exchange keys?
Not to sound elitist, but if you're not compiling from source, then you should contact your software vendor for information as to what the hell they've done. It is especially annoying if it is not documented (in something other than the source code) what they've patched, if they haven't changed the version number at all.
This is what I get:
clf:~> ssh -V
ssh: SSH Version 2.0.13
I'm ok, right?
Certainly the Open distribution of BSD comes with a more secure-by-default installation configuration than does the Redhat distribution of Linux. But other concerns are often preëminent. For example, perhaps you want a pre-installed version of KDE and StarOffice so that your secretary can use it.
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.
but does rsaref qualify as a "machine?"
-dk
Dream with the feathers of angels stuffed beneath your head.
You must check what flavor of ssl you've got. If you have sslUSA, you might be affected. check the openbsd advisory on sslUSA for more info. --kelsey
To exploit them, read The Tao of Buffer Overflow, a well-written tutorial on how to crack a system that has a buffer overflow.
It's a real problem. All the safer languages that were fast (Modula, Pascal, Ada) have died off. C++ was on the right track until the Standard Template Library came out with its unsafe iterators; now there are whole new classes of holes.
Sorry for the rant. I used to work on secure operating systems, and things aren't getting better; they're getting worse. What passes for "secure systems" today is pathetic.
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.
So what's the plural of "penis"? "Penides"? Or "dicksen"? :-)
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.
Right, but anyone on Bugtraq has known about this for a long time, and has had plenty of time to upgrade to OpenSSH or SSH2. And if you're actually running Linux and not reading Bugtraq, IMO you're pretty much asking to get rooted.
And anyway, SSH is the kind of thing you _should_ build from source, no matter how nice RPMs are. I mean, hell, I love rpm, but do you know who built those RPMs on rpmfind? I could easily build a trojaned SSH (for instance, make it so the RNG subsystem always returns 0, so your keys are easy to guess) and submit it to rpmfind (faking the hostname, etc so it looks like it came from redhat or SSH). If it came from RedHat's ftp site (and the GPG signature validated), I would probably consider it, but getting SSH from someone you don't know is not particularly smart. Just get the source from the official site (somewhere in finland, check www.ssh.fi for links) and build it yourself.
For instance, I get PGP/GPG RPMS from ftp.gnupg.org and ftp.pgpi.org because they are trusted sources, so I'm ok with that. I also trust the SSH ftp site: if they had RPMs there I would get them, but they don't, so I build from source. But I won't trust some random person who submits to rpmfind.
The CERT advisory seemed to imply that the vulnerability existed not only in ssh but also sshd. This would make sense, considering the nature of the hole. Is there a difference between the client and the daemon; in other words should I be worried about sshd if ssh is clean? I would hope that there is a large enough code base in common between ssh and sshd that if one is clean the other is too, but I'm not so naive as to assume that anyone writes good code these days ;) So I guess the question is-- if ssh -V is okay, does that mean that sshd is okay too?
-- You are in a maze of twisty little passages, all alike.
If when I type 'ssh -V' I get:
SSH Version OpenSSH-1.2, protocol version 1.5. Compiled with SSL.
Is that all right? It doesn't mention RSAREF, so I wasn't sure. I suspect it's fine, given that it doesn't directly mention RSAREF, but I thought I'd check.
Thanks,
David Andre
It's generally a good rule of thumb to build your own binaries, especially security related ones, that way you've got no one else but yourself to blame.
--rp
hahahahahahahaha
gasp gasp... pant
muahahahahahahahahahahahahahahahah hee
tee hee... heeeeeee....
/Joakim Crafack
... Elecance is left to the implementors.
ssh is open source. RSAREF is the closed source (patented) library that is at issue. The vulnerability exists in RSAREF and affects all these other products.
Personally, I'm glad Debian distributes its ssh without RSAREF.
Would the vulnerability exist if RSAREF was open sourced? I doubt it. There are plenty of other RSA implementations that don't have this problem.
Using your sig line to advertise for friends is lame.
To quote for the advisory:
OpenSSL
OpenSSL with RSAREF is not vulnerable.
OpenBSD / OpenSSH
and following the subsequent link to the OpenBSD page:
"A buffer overflow in the RSAREF code included in the USA version of the libssl package (called sslUSA, is possibly exploitable in httpd, ssh, or isakmpd, if SSL/RSA features are enabled or used. NOTE: International users using the ssl26 package are not affected."
--
Flames? Think I'm a karma whore?
At least for now, ssh -V yields:
SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5.
Standard version. Does not use RSAREF.
I guess I'm OK, although I'd like to be out from under these silly Patent restrictions. :(
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.
somebody please mod that guy back down... this only encourages people that snap at each other to be modded up.
This is why auditing your code has become so important. At least with Open source we can patch it ourselves with out waiting for a vendor. I like to come up with a "user supplied input tree" and look for trouble spots.
Microsoft aggravates my tourettes syndrome.
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.
Having read the code for RSAREF1 and RSAREF2, refuse to use either. RSAREF2 seems to just be a minor patch release for RSAREF1 (do the diffs and see for yourself.). The code is pretty ugly, it is not 64bit clean code, and is a pain to compile.
With much better RSA libraries out there, why use it, other than the legal threats from RSA.
"Trademarks are the heraldry of the new feudalism."
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
NiftyTelnet supports SSH on Mac?! I've been waiting for ssh support in a Mac client for quite some time, so I was initially quite excited to hear you say that...
However, I checked out the NiftyTelnet home page and they don't mention SSH support anywhere. I downloaded it and the application didn't have any SSH options either. Perhaps you are speaking of the Kerberos authentication support?
I'm looking for end to end encryption, so if I'm wrong about this, please let me know!
Culture is more than commerce
Reply to the 115th post!!!!
Is it just me or have others of you known about this for quite a while? :)
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
---------------------------
Are supposedly not affected, because RSAREF shouldn't have been exported from the United States.
Is it just me, or is this almost laughable?
Can anybody tell me with a straight face that nobody has illegally exported? Statements like that make me curious-- how comfortable is it, really, to have your head buried in the sand?
Anyway, I wasn't writing this to be a troll. It just struck me as funny that CERT would try to act like international users aren't affected because of export laws. Nobody is going to steal my car, because there are laws against it, right?
from www.openssh.org/security.html OpenSSH was never vulnerable to the recent (November, 1999) security issue in Datafellows SSH. This has been on bugtraq and vuln-dev for a while now.
FYI:The OpenBSD list is a little different, if you check the link. This is primarily for FreeBSD, but I posted it as the BSD family, since many people run FBSD apps and packages on other flavors...
"It's tough to be bilingual when you get hit in the head."
And how does the performance compare?
Logic ... merely enables one to be wrong with authority. -- Doctor Who
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.
hmm. is this the same security bug that got Segfault.org rooted and taken down for a bit?
0 88-03dd8580
"Hey folks, thats right we're back. The story is that Leonard's uni machine got hacked, and the hacker got into us using ssh (and you thought it was safe!). The hacker didn't seem to do anything, but he had compromised a few binaries (looked like a script kiddie root kit) so it was reinstall time... [continues]" --segfault this morning
http://segfault.org/story.phtml?mode=2&id=3846d
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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
And there's nothing to stop you from compiling Java into machine code instead of Java byte code...
ssh2 does not implement the ssh1 protocols, so
ssh2 simply execs ssh1 when a v1.5 client
connects. Everyone installs ssh2 in ssh1
compatibility mode because the free Mac/Win ssh
clients, like NiftyTelnet and ttssh, only do ssh1.
The ssh1 RPMs currently on ftp.hacktic.nl and
mirrors (replay.com is no more) have been patched
to avoid this problem. I assume debian is OK too.
All the BSD's use OpenSSH now, so they're fine as
long as you're up to date.
Unamericans should be OK because they don't link
with RSAREF.
Americans who haven't linked with RSAREF are
violating RSA's patent.
Well, I abide by a simple rule. If feds approve it, I don't use it.
I'll stick with Blowfish, thank you. It's not exportable... and therefore better than what is.