Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
News

Security Hole in SSH1 with RSAREF 160

Posted by jamie from the don't-panic dept.
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.)
This discussion has been archived. No new comments can be posted.

Security Hole in SSH1 with RSAREF More

Security Hole in SSH1 with RSAREF

Comments Filter:
  • 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.

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

  • If you get hacked because of this bug, please write a nice "thank you" letter to the U.S. Patent Office.

    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!

    I think RSA believes their patent enforced monopoly entitles them to write sloppy, slow, poor quality code.

    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.

  • Making the stack nonexecutable makes buffer overflow attacks harder, but not impossible. A buffer overflow of a stack variable can still overstore a return address, so the attacker can cause control to be transferred to any chosen point in the program under attack. If the attacker can find someplace in the program that will do something for them, they're in.

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

  • NiftyTelnet SSH (Score:1)

    by Anonymous Coward
    There is a version of NiftyTelnet that was extended to include support for SSH and SCP. Due to patent restrictions, you may or may not be able to legally use it. Your only other choice is the Data Fellows, Inc. [datafellows.com] client, which costs about $100, I think.

    Visit http://www.lysator.liu.se/~jon asw/freeware/niftyssh/ [lysator.liu.se] 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??
  • 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 [ogi.edu]. 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 [insecure.org]. You can also check out disabling an executable stack on Solaris [uwaterloo.ca], and why this isn't a cure-all [cam.ac.uk].

    Even with a non-executable stack, you can still be bitten. Several such exploits have appeared on bugtrak. Here's one [fi.upm.es]. 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 [indiana.edu] 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 [deja.com] the promised gem of insight from Dennis [bell-labs.com]:

    > ..... 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? :-)
  • 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.
  • "Under the terms of the RSAREF license, changes to the RSAREF code other than porting or performance improvement require written consent. RSA Security hereby gives its consent to implement a patch to RSAREF to address this advisory."

    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.
  • It's interesting that the CERT advisory was dated yesterday.. I saw a notice a couple weeks ago here [securityfocus.com], 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.


  • Is this fixed already? (Score:4)

    by rangek ( 16645 ) on Tuesday December 14, 1999 @06:53AM (#1465847)

    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?

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

  • www.zedz.net RPMS already updated (Score:3)

    by bholzm1 ( 26184 ) on Tuesday December 14, 1999 @06:56AM (#1465850)
    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.
  • I just installed SSH1 v1.2.27 last night on a new machine. I got lazy and installed via a SRPM, and didn't do anything more than 'rpm --rebuild ./ssh-1_2_27-5us_src.rpm'. It's uses RSAREF. Bummer.

    -B

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

  • OpenSSH? (Score:3)

    by Kaa ( 21510 ) on Tuesday December 14, 1999 @06:19AM (#1465857) Homepage
    What about OpenSSH from OpenBSD people? Is it affected as well?

    Kaa
  • 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!

  • Affected Items (Score:3)

    by Tower ( 37395 ) on Tuesday December 14, 1999 @06:21AM (#1465863)
    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
  • Every implementation which is based upon RSAREF1. It's a problem in the source (free available btw)
  • Why don't you read the advisory [cert.org]?
  • It's kinda hard to audit code that's not released...(i.e. RSAREF)



    "If you're going to make claims back them up or get out of my fucking face."




    I suggest you do the same. You don't have very convincing arguments about OpenBSD source auditing being an "urban legend". And it is still considered the most secure OS around.

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

  • 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.
  • 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
  • Here:

    FUNCTIONALITY ADDITION: Nov 11, 1999 Various OpenSSH improvements have been made since the 2.6 release shipped. To resolve the various (non-security related) features which users may want, we are making a jumbo patch available. This is now at VERSION THREE. Revision 3 of this jumbo source code patch exists. NOTE: /etc/sshd_config and /etc/ssh_config may need changes.

  • 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!

  • Actually it isn't :)

    The OpenSSH implementation checks all outputs it gives, as well as all inputs it gets, so it won't cause the bug.

    This is according to Theo himself, who seems far too precise (OK, anal) to let pride get in the way. Me, on the other hand, correcting myself for the second time, am obviously fine spewing crap out. sigh
  • Ehm I think certainly the vanilla pgp is safe, and probably all the other pgps to... See the statement that is linked in the story.

  • > It's kinda hard to audit code that's not released...(i.e. RSAREF)

    Hmmm... that's funny. I have the source to RSAREF right here in front of me. I'm sure millions of other people do too.

    --

  • For more details on OpenSSh and OpenBsd check out this BugTraq posting [securityfocus.com] on the issue.
  • Fundamentally, it's a "demo version" of BSAFE, which is RSA Data Security Inc.'s real product, the one they sell you for money, put actual effort into, optimize, etc. Since RSADSI (the company) owns the relevant patents on RSA (the cipher) in the USA until September 20, 2000, it's up to them to dictate terms and tell you what you can and can't do with their patents. It turns out they're not too bad at heart, as evidenced by a correspondence I had with their Chief Scientist, Burt Kaliski. (Dr. Kaliski has published many useful papers on cryptography, and is well known in the field) -- The intent of the RSAREF license is to support research and other non-commercial development activities. For commercial development, RSA Data Security's preference is to license its commercial toolkits such as BSAFE (or the recently announced BSAFE SSL toolkit, which is available worldwide). --

    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

    • RSA is a company of reasonable human beings who want you to pay them for making money off of their patented technologies
    • Only users in the USA are affected by the RSAREF situation, which suits both parties poorly, as users get crappy support and RSA wastes uncompensated effort any time they have to fix it
    • OpenSSH, for example, is freely available, supported (after a fashion), and does not incur monetary losses to RSA when deployed for R&D purposes, eg. researching secure network protocols

    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.

  • Here's the OpenSSH advisory [openbsd.org] on the subject.

  • just installed SSH1 v1.2.27 last night on a new machine. I got lazy and installed via a SRPM, and didn't do anything more than 'rpm --rebuild ./ssh-1_2_27-5us_src.rpm'. It's uses RSAREF. Bummer.

    See my other post. [slashdot.org]

    I think 1.2.27-7us fixed this bug.

  • If it were Theo he would have gotten it right.
  • My understanding is that there are TWO problems, one dated December 1, and one dated December 13.

    From BUGTRAQ in a message by Iván Arce (http://www.core-sdi.com):

    As noted in the advisories (
    http://www.core-sdi.com/advisories/buffer%20over flow%20ing.htm
    and http://www.cert.org/advisories/CA-99-15-RSAREF2.ht ml )
    there are TWO buffer overflows. The first is in the SSH distributed file rsaglue.c the second is in the rsa.c file that is part of the RSAREF2 distribution.
  • 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 :)
  • 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.
  • Since the replies up to the time I started writing this were needlessly rude and unpleasent, I thought I'd answer you.

    Thank you for unexpected civility (and on Slashdot, of all places! What the world is coming to?...). The assholes were rude and wrong.

    A quote from the OpenBSD web page:

    NOTE: OpenSSH does not have the ssh 1.2.27 rsa bug.

    but also

    SECURITY FIX: The USA version of the ssl library package, called sslUSA26, contained buffer overflows. A binary patch is available for people who installed before December 3.

    and

    The third ssh jumbo patch is now available. Numerous (non-security) additions/changes have been made to OpenSSH since the OpenBSD 2.6 release.


    Kaa

  • 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 [w3.org]. The us versions here are compiled with RSAREF. But I think the latest version fixes this. See my other post [slashdot.org].

  • 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
  • Very simple. If you don't compile the source or patch the code yourself, you have no way of knowing what, if anything, your RPM/etc. is patched for, which specific CERT advisories, etc.

    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.

  • Woooops, mistake from my part here...sorry for that, I'm reading the RSAREF license right now to punish myself...
  • I think they were waiting to get a patch written, and to give all the vendors time to do their research.

    Core SDI developed the exploit. CERT is just notoriously slow ... which is a shame, because most vendor patches don't come out until after the CERT vulnerability.
  • This is what I get:


    clf:~> ssh -V
    ssh: SSH Version 2.0.13


    I'm ok, right?
  • RSAREF is the library that American users are obliged to link with because of silly patent stuff. Those of us outside the US can use better international libraries, which do not suffer from this bug. Since ssh -V tells you that you're not using RSAREF, you should be fine.

  • 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.
  • That is correct. Also, to dispell the urban "legend", the ssh volunerability was posted to bugtraq by...guess who? Theo De Raat, the lead programmer for OpenBSD.

    Their code auditing is what discovered this in the first place.
  • but does rsaref qualify as a "machine?"

  • You must check what flavor of ssl you've got. If you have sslUSA, you might be affected. check the openbsd advisory on sslUSA [openbsd.org] for more info. --kelsey
  • The real problem is the C programming language, and its casual attitude toward subscript checking. Trusted software shouldn't be written in C. The number of security holes generated by this issue alone is in the hundreds. Sendmail is notorious for this.

    To exploit them, read The Tao of Buffer Overflow [cultdeadcow.com], 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.

  • Most likely, it would have been found by /someone/ who was semi-randomly pounding on a test binary, just like the way a lot of other exploits are found in binary-only products. They wouldn't necessarily tell anyone, in fact, they might well keep it secret until they'd used it to transfer as much wealth or information as they wanted to their own hands. Or they might tell all their friends on some irc channel. Open Source programs are not immune to this, obviously. However, the access to source code means that concerned users can audit it themselves, rather than the holes being found by people who want to use them for their own, possibly criminal, ends. It also encourages the developer to write better code in the first place, since there'll be other people looking at it.
  • Only users in the USA are affected by the RSAREF situation, which suits both parties poorly, as users get crappy support and RSA wastes uncompensated effort any time they have to fix it

    Our good friend, Theo de Radt, said as much. OpenSSH checks the args to the RSAREF package strictly, and so is not vulnerable. SSH1 w/ RSAREF is vulnerable (and there is aparently a working exploit). Any packages that use RSAREF might also have holes (OpenSSL, etc).

    Here [openbsd.org] is a good graphic describing the encryption situation :-) RSAREF, export restrictions, etc, all contribute to it.
    ---
  • I saw your post and went and got a copy. Yeah, it fixed the hole. But I'm just going to go ahead and install 1.2.27-7us via sources instead of SRPM anyway.

    I shoulda been installing SSH via sources anyway.

    -B

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

  • Re:OpenSSH? (Score:2)

    by Anonymous Coward
    OpenSSH [openssh.com] is not vulnerable to this exploit. Mail from Bugtraq:

    Subject: Re: Security Advisory: Buffer overflow in RSAREF2
    From: Niels Provos
    Date: 1999-12-04 22:45:20

    In message , Gerardo Richarte writes:

    To make this clear: in combination with the buffer overflow in rsaglue.c this makes possible to get a remote shell on a machine running sshd AND it also makes possible to use a reverse exploit to gain access on clients' machines, using malicious sshd.

    I fear that this posting should have been even clearer. To sum the problem up more clearly:

    ssh-1.2.27 (if compiled with RSAREF2) is vulnerable. Attackers can obtain a shell on the machine running sshd. The exploit uses buffer overflows in the RSAREF2 implementation AND in the rsaglue.c file in ssh-1.2.27. I am surprised that there wasnt a bigger outrage on the mailing list about this, it is quite serious!!!

    On the other hand, OpenSSH is not vulnerable to this remote exploit. Since rsaglue.c was rewritten, OpenSSH does stricter parameter checking than ssh-1.2.27 and these recent problems in ssh-1.2.27 did NOT affect OpenSSH.

    Nonetheless, OpenSSH users in the USA that use OpenSSL compiled with RSAREF2 should update their ssl library (since isakmpd or httpd may be affected), see previous postings on Bugtraq, and http://www.openbsd.org/errata.html#sslUSA [openbsd.org]

    Another thing is worth mentioning, RSA could use the buffer overflow in RSAREF2 to scan machines in the USA for RSA license violation. For example, sshds that do not use RSAREF2 do will behave differently than those that do.

    Information on OpenSSH can be found at http://www.openssh.com/ [openssh.com]
    Information on OpenSSL can be found at http://www.openssl.org/ [openssl.org]

  • Potato uses OpenSSH as the default SSH client, ssh -V reports: SSH Version OpenSSH-1.2, protocol version 1.5. Compiled with SSL. Martin

  • sshd? (Score:1)

    by cxd204 ( 88926 )
    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?

  • 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
  • Actually, as I recall the discussion on the OpenBSD mailing list when this came up a week or two ago, this bug compromises the security of an OpenBSD system in the US only (due to our wonderful patent laws). Further, the latest version of OpenBSD (2.6) is not I repeat not affected by this, since it uses OpenSSH -- an implementation of SSH that has undergone their scrutiny.

    As for that "urban legend," you're smoking crack. OpenBSD is very up-front that everything in the base installation has undergone extensive testing; ssh, because it is not free software, is not in the base install. Idiot.
  • 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....

  • Re:The problem is C (Score:1)

    by Anonymous Coward
    no, the real problem is: an executable stack.

    If the stack was not executable, buffer overflows would be a denial of service attack, not an opportunity for an attacker to root your machine.

    Most buffer overflow attacks take advantage of unchecked array limits to put malicious code on the stack and forge the return address of the non-bounds-checking subroutine to make it execute that code. That code then performs some system calls that drop the security of your machine to zero...

    If the stack isn't executable, executing that "malicious code" generates a seg fault or memory trap... I'd rather have my sshd seg fault and die, as opposed to letting someone root my machine.

  • Uhh, OpenBSD didn't 'write' OpenSSH, they went back to the last version of SSH that had a free license and then backported all necessary security fixes.
    Aside from that, you're right :)

    Daniel
  • ...can be found here [securityfocus.com]

    /Joakim Crafack

  • I think this might be debatable. If only the binaries were released, would the problem have been found in the first place? It might have lived happily and undiscovered for months. Not to say anything bad on open source programs. Far from it.
  • 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.
  • 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?
  • Since the replies up to the time I started writing this were needlessly rude and unpleasent, I thought I'd answer you.

    OpenSSH -is- affected, at least for older versions for the US. International versions are not affected, and I believe the latest OpenSSH for the US is also not affected.

  • SSH 2 availability (Score:1)

    by Anonymous Coward
    When I first looked at SSH 2, it did not appear like its license was free - in fact it looked far from it. Is there a *free* version available now? I've been using version 1 because the license appears more friendly.

    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.

  • Not very bad (Score:3)

    by fremen ( 33537 ) on Tuesday December 14, 1999 @06:33AM (#1465946)
    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.
  • Yeppers. It's just that gnorpm is sooo sweet I can't resist using it. ;)

  • Very simple. If you don't compile the source or patch the code yourself, you have no way of knowing what, if anything, your RPM/etc. is patched for, which specific CERT advisories, etc.

    Sure you do. You check the changelog. If you don't trust the packager, get the source package and look it over. If you really don't trust the packager, get the tar.gz sources.

    All I was asking was whether the message in the changelog I saw was about this bug or another, new one. I was confused because I got the fix weeks ago, and heard about it several other places weeks ago. Now all of a sudden it pops up on Slashdot.

    So the problem isn't packages, it is the variable pace of news on the net. I.e., it apparently takes CERT quite a while (~2 weeks) to publish a notice, by which time the fix is already in place on quite a few systems.

    And I don't think there is anything elite about installing raw source all the time. You try to manage a few dozen workstations and servers running quite a few packages not found in the standard distribution (RedHat in this case) without package management. Hardly possible, I assure you.

    Package management is something I am thankful for everyday. Hell, I even make packages for software that is only released internally because it is just so much easier to install that way.

  • 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.
  • Geez what an angry thread - take a freakin stress tab.

  • The classical rules would say to use the following for "singular, plural":
    • clitoris, clitorides (Greek)
    • penis, penes (Latin)
    • vagina, vaginae (Latin)
    • testis, testes (Latin)
    • scrotum, scrota (Latin)
    • larynx, larynges (Greek)
    • pharyx, pharynges (Greek)
    (Yes, the last two could theoretically occur in sexual contexts. But Sphinx/Sphinges probably wouldn't. :-)

    In practice, only medical texts tend to do so. (Now you know why physicians take Greek and Latin.) The rest of us just add the normal English endings. It's not like these comes up very often in pillow talk.

    You can see the -ides inflection in compounds:

    % look clitori
    Clitoria
    clitoridauxe
    clitoridean
    clitoridectomy
    clitoriditis
    clitoridotomy
    clitoris
    clitorism
    clitoritis
    As for irides (literally, rainbows), hm... I suppose some of these naughty bits might on occasion be iridescent.

    I'm glad slashdot has never done a feature article on how to talk dirty in Latin [obscure.org]. Otherwise we'd doubtless be innundated with requests for Natalia the Irrumatrix. :-)

    And no, "Irrumatrix" isn't the bootleg, uncut, XXX-rated version of that silly Matrix movie with Keanu caught doing the naughty. Then again, with recent advances in digital technology, one never knows what they might come up with. :-)**2

  • I as ked about this [sigmasoft.com] on the OpenBSD [openbsd.org] tech mailing list [openbsd.org], and Theo de Raadt [mailto] as sured me that it didn't [sigmasoft.com].

  • this bug compromises the security of an OpenBSD system in the US only
    Excuse me, I didn't quite get this one right: please insert "if installed before the patched RSAREF was available and not updated since" before "only".
  • Isn't this what caused the demise of RootShell [rootshell.com]?

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

  • 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!

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

  • CERT/CC Comments on Slashdot discussions (Score:2)

    by Anonymous Coward

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

  • Beware Of Geeks Bearing Gifts, eh? (Score:3)

    by Effugas ( 2378 ) on Tuesday December 14, 1999 @12:20PM (#1465981) Homepage
    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
  • 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.
    No, that's not true. Perl doesn't put code on the stack. Each Perl interpreter (and yes, one program can comprise several of these) keeps its own "virtual" stack. What goes on there are not machine op-codes, but Perlish ones.

    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:

    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-commercial _licensing.html

    So it all depends on what position you are in. Works great for me(tm)

Slashdot Top Deals

[FORTRAN] will persist for some time -- probably for at least the next decade. -- T. Cheatham

Close