Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Bug

OpenSSL Security Update 224

Posted by michael from the whoa,-how'd-that-get-in-there dept.
Pseud0 writes "Just announced on the OpenSSL announce mailing list. The affected versions are "[...] OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable." Get your updates here."
This discussion has been archived. No new comments can be posted.

OpenSSL Security Update More

OpenSSL Security Update

Comments Filter:

  • Logic behind this (Score:2, Insightful)

    by Your_Mom ( 94238 )
    OK, lets announce a major secuirty whole in a prouct that a good chunk of people use, then link to their website so that no one can download the patch(es).

    Yeah... Real smart.

    Honestly, when I want security updates, I'll read BUGTRAQ, when I want light fluff about the latest Stallman-ism, I'll read /.
    (Still, if you want to do this, add a security section or something, jeez)

    • Well, most of us shouldn't have to download the patches. Instead, we wait for our favourite distribution to come up with rebuilt packages and then install. At least in redhat, debian and mandrake. Probably others.

      But... i agree with you, sort of. I understand that something of this scale is newsworthy, but still most of us don't need the source and/or patches directly. That's what rh's errata (and similar) are for. So, the actual announcement could have been slightly more subtle, or something...

      But people shouldn't "want" security updates, people _need_ security updates, so i guess that's the reasoning behind this news story.

      • I gave up on packages a long time ago. Debian never had the latest versions of programs in their database, and it was too much of a pain to deal with the whole dselect tool. Thus I've got to have the sources to compile all my applications.

        Plus, if you don't compile it yourself, who knows what extra goodies are being installed that you don't want.

        • Well, that's always the thing between source and binary distros.

          And really, in most cases you don't need to be up-to-date instantly. Think about updating browsers etc.

          Plus, if you don't compile it yourself, who knows what extra goodies are being installed that you don't want.

          Well, that's a question of trust (and MD5-signatures), but, honestly, how many of us go through the source, line by line?

          (but i'm a gentoo user myself, altough i use redhat at work. i don't like to think of myself as biased in any way.)

      • So, binaries are good. You just have to wait few days with a root compromise in your computer. Sorry, I don't like have huge holes in my server while waiting for a vendor patch, just a personal thing.

        (Honestly, you shouldn't either, thats why you should patch any hole immediately)

        • Ok, you have an extremely good point there. I _don't_ think that people should just accept vulnerabilities, altough in most cases you can accomodate, shut down non-critical services etc.

          But really, if you happen to be vendor-dependent, then there's not much you can do. Of course you could build it yourself,replace the binaries and fix the packaging system used later (when it arrives). I did this last time openssh had issues. But with openssl i don't think you can get away that easily.

          Still, oh well, back to slackware, then.

      • Re:Logic behind this (Score:5, Informative)

        by spudnic ( 32107 ) on Tuesday July 30, 2002 @10:47AM (#3977920)
        This may sound like a plug for the RHN Enterprise service, because it is. I got in this morning at around 7:50, checked the status of all of my Red Hat servers through the web page and saw that there was an urgent update available for OpenSSL. I clicked 3 times and all of them were scheduled to get the update the next time they checked in.

        It's now 9:44 and all of my servers are patched. It took me 5 seconds to schedule it, and just drank coffee and read /. as it happened.

        It's well worth it. We're all sold on it, and the Novell guys are envious.

    • Actually, the announcement which was distributed on the openssl-announce mailing list, comes with the patch as an attachment - about 16k long.

    • Posting it on slashdot is a good way to get the word out about the vulnerability. The fact that it got /.'d hardly means it shouldnt have been posted. Atleast more people know about it now, and will update eventually. Also, patches were sent out through bugtraq, so if you're subscribed to that you already have the patches in your inbox.
    • Bugtraq's signal-to-noise ratio is much lower than /.'s when it comes to relevant security vulnerabilities, IMO. Bugtraq has shit like "Easy Guestbook" "W3Mail" and "phpBB" all the time. Barely readable.

  • Mirrors list mirrored (Score:5, Informative)

    by Olinator ( 412652 ) <olc+sdot&hex,cs,umass,edu> on Tuesday July 30, 2002 @10:11AM (#3977718) Homepage
    Here [umass.edu]. (I tried to submit this story with this link, 'cause the site was going down before it appeared on /.; guess I wasn't fast enough.)
    Ole
    • Thanks a lot. I can download now. woohoo! Of course, the UMass sysadmin is going to be wonder why 50,000 geeks are clicking to your home directory now.

      Personally, I would expect an e-mail from him :)
      • Blockpoth the quoster:
        Of course, the UMass sysadmin is going to be wonder why 50,000 geeks are clicking to your home directory now.

        "Naah, I removed those pictures months ago."

        Besides, I'm used to getting email from UMass sysadmins -- although now I suppose we're going to have to quibble about who gets to claim the title of "The UMass sysadmin". (It's a largish school, there are a lot of us -- usually multiple BOFHen per department, particularly in the sciences.:)

        Ole
        (Who's been accused of many things, but never schizophrenia.)
    • A very good idea, but unfortunately most of the mirrors don't have 0.96e available and now they probably won't be able to update until the master site stops being overloaded :(

      Would have been quite helpful if the announcement (particularly the announcement on the front page here) could have been held until after most of the mirrors had updated.

      It might actually be a very good idea to move this story off the main page for a few hours...

    • the only mirrors that seem to actually have this are:

      # ftp://opensores.thebunker.net/pub/mirrors/openssl/

      and ftp.openssl.org

      all the other's i tried weren't up to date.

  • Question (Score:3, Interesting)

    by Ender Ryan ( 79406 ) <MONET minus painter> on Tuesday July 30, 2002 @10:14AM (#3977734) Journal
    What is the difference between openssl-engine-0.9.6e.tar.gz and openssl-0.9.6e.tar.gz?

  • How about some common courtesy? (Score:5, Insightful)

    by gosand ( 234100 ) on Tuesday July 30, 2002 @10:15AM (#3977738)
    For crying out loud, how about at least putting the text of the security alert in the story. Honestly, how hard would it have been to do that? Now all I know is that there is some security issue with OpenSSL, and I can't get to the site to even see what it is. I know /. can't control the fact that sites get slashdotted, but you could be a little more considerate and give us SOME information.

    • Re:How about some common courtesy? (Score:5, Informative)

      by tbmaddux ( 145207 ) on Tuesday July 30, 2002 @10:26AM (#3977805) Homepage Journal
      Found details on vulnerabilities (don't know if they're the same ones as the ones being patched) in OpenSSL at bugtraq:
      "There are several potentially exploitable vulnerabilities in the OpenSSL toolkit. A security review of OpenSSL is being done by A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) under the DARPA program CHATS. Through this review, the following vulnerabilities were discovered:

      1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulnerability is exploitable.

      2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

      3. Various buffers for ASCII representations of integers were too small on 64 bit platforms.

      4. The ASN1 parser can be confused by supplying it with certain invalid encodings.

      The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0655 to issue 3, and CAN-2002-0659 to issue 4.

      Here's a link [securityfocus.com].

      • > 1. The client master key in SSL2 could be oversized and overrun a buffer.

        > 2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

        Forgive me for opening the language flamewars again, but doesn't anyone else find this "a wee bit inexcusable" in software designed for secure network access?

        As has been mentioned here countless times before, there are languages that disallow buffer overflows (period), and for people who don't want to use those languages there are libraries that replace built-in I/O functions for the same effect.

        Hasn't it occured to anyone in the security industry that buffer overflows are a serious threat, and for things like SSL, BO-proof coding should be adopted as a matter of policy, rather than as a bug-to-fix-when-we-catch-it?

        I'm not trying to villify anyone, and I'm really glad to see that someone has been hired to do a thorough security audit... but I just find this kind of thing completely incomprehensible, when it's so easy to avoid it in the first place.

        • For that matter, if it's possible for libraries to take care of this, why isn't libc (or whichever) fixed to handle this itself? It seems like that'd be a great area to spend effort.
          • For that matter, if it's possible for libraries to take care of this, why isn't libc (or whichever) fixed to handle this itself? It seems like that'd be a great area to spend effort.

            A few reasons:

            • First of all, bounds checking on an array in C would cause some working (but probably poorly written) programs to stop working.
            • Secondly, the overhead to check bounds could be quite signficant. Right now an array lookup is just bit of math (probably a shift and add) followed by a load or store. This would greatly increase the amount of math required and would add at least one more load (to find the bounds). So every single array access would slow down!
            • Third, and this one I'm less sure of, I think that in C you often have reasonable code where it would be almost impossible for the compiler to do the bounds check. C just wasn't designed with this in mind.
            • Forth, I know I've used pointers to into arrays before. Without a great deal of care the same buffer overflow problems could occur due to the pointers.
            My point: the way C code is written, as well as the C language itself, makes doing 100% solid bounds checking basically impossible.

            • > My point: the way C code is written, as well as the C language itself, makes doing 100% solid bounds checking basically impossible.

              If true, that sounds like sufficient reason to avoid using C when writing secure networking software.

              • C has one very good feature for writing secure software, namely that it's comparatively easy to figure out exactly what your program is doing, compared to C++ (where simply creating an automatic variable can invoke all sorts of constructor weirdness), let alone interpreted languages.

                Talking to a guy who writes security software based on OpenBSD (and works on OpenBSD in his spare time), that's why he preferred to use C (in very small programs, containing only the bits of code that absolutely had to run as root and using some form of interprocess communication to talk to the bells-and-whistles provision daemon) for security-critical daemons.

    • Happy Xmas (Score:5, Informative)

      by fingal ( 49160 ) on Tuesday July 30, 2002 @10:30AM (#3977826) Homepage

      OpenSSL Security Advisory [30 July 2002]

      This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory.

      Advisory 1

      A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are conducting a security review of OpenSSL, under the DARPA program CHATS.

      Vulnerabilities

      All four of these are potentially remotely exploitable.

      1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulerability is exploitable. Exploit code is NOT available at this time.

      2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

      3. The master key supplied to an SSL3 server could be oversized and overrun a stack-based buffer. This issues only affects OpenSSL 0.9.7 before 0.9.7-beta3 with Kerberos enabled.

      4. Various buffers for ASCII representations of integers were too small on 64 bit platforms.

      The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0657 to issue 3, and CAN-2002-0655 to issue 4.

      In addition various potential buffer overflows not known to be exploitable have had assertions added to defend against them.

      Who is affected?

      Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable.

      SSLeay is probably also affected.

      Recommendations

      Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or TLS.

      A patch for 0.9.7 is available from the OpenSSL website (http://www.openssl.org/).

      Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release versions with Kerberos enabled will also have to disable Kerberos.

      Client should be disabled altogether until the patches are applied.

      Known Exploits

      There are no know exploits available for these vulnerabilities. As noted above, Neohapsis have demonstrated internally that an exploit is possible, but have not released the exploit code.

      References

      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0655

      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0656

      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0657

      Acknowledgements

      The project leading to this advisory is sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537.

      The patch and advisory were prepared by Ben Laurie.

      Advisory 2

      Vulnerabilities

      The ASN1 parser can be confused by supplying it with certain invalid encodings.

      The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0659 to this issue.

      Who is affected?

      Any OpenSSL program which uses the ASN1 library to parse untrusted data. This includes all SSL or TLS applications, those using S/MIME (PKCS#7) or certificate generation routines.

      Recommendations

      Apply the patch to OpenSSL, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL.

      Users of 0.9.7 pre-release versions should apply the patch or upgrade to 0.9.7-beta3 or later. Recompile all applications using OpenSSL.

      Exploits

      There are no known exploits for this vulnerability.

      References

      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0659

      Acknowledgements

      This vulnerability was discovered by Adi Stav and James Yonan independently. The patch is partly based on a version by Adi Stav.

      The patch and advisory were prepared by Dr. Stephen Henson.

      • If you have it, can you post the patch too? (If the lame filter allows it, of course...)
        • If you have it, can you post the patch too? (If the lame filter allows it, of course...)

          I do have it, but I left it off because of the amount of mangling that I had to do to the message to get it to accept that I thought it was unwise to do the same to a patch...

          Doh! received it on suse-security, so here is a link [suse.com] to their archive of the mail (including patch). Enjoy...

    • I can still read it:
      It's a little slow.

      But i really should post a mirror. ...

      but then the "Lameness filter encountered. Post aborted!
      Reason: Please use fewer 'junk' characters."
      does not allow a post of this on this page.

      2 Vulnerabilities
      --------------- The ASN1 parser can be confused by supplying it with certain invalid
      encodings. The Common Vulnerabilities and Exposures project (cve.mitre.org) has
      assigned the name CAN-2002-0659 to this issue.

      Damn, my application is not even yet realeased and already i must check it's security. I should use the openssl library veriosn 1.0.

    • If you care about security, you should be reading Bugtraq [securityfocus.com]. As soon as I saw the title I checked my email and read the real advisory - now that I'm done upgrading, I can come back and see what Slashdot says about it.
      • If you care about security, you should be reading Bugtraq

        Then why would the story even be posted here? *IF* they are going to post a story like this, they should put some information in the story. Otherwise, why bother? They had to have the info sitting right in front of them. Do you know how many hits that would have saved the other websites? Slashdot is about reposting stories, it is a meta-news site. News for Nerds and all. Pointing me to another story without giving me any details isn't news.

  • The Slashdot effect - enough is enough (Score:4, Insightful)

    by pieterh ( 196118 ) on Tuesday July 30, 2002 @10:18AM (#3977754) Homepage
    As a poster noted, it is quite ironic that /. effectively acts as a DoS against web sites. Yes, I'm trying to download the update to OpenSSL, an excellent product that we use in our applications. No, I can't reach their site, because millions of /.ers are trying to read the site.
    Isn't it time that /. did a Google? It cannot be so difficult to mirror a site and refer to that instead of the prime site?
    I like reading and posting here, but the /. effect is not just really annoying and traumatic to those sysadmins exposed to it, it's unpolite, and it's unnecessary. CmdrTaco, please consider doing something smarter to mirror targetted sites.
    • Wow, you mean people actually go read the article before posting?

    • Re:The Slashdot effect - enough is enough (Score:2, Insightful)

      by Anonymous Coward
      RTFM: Why Slashdot doesn't cache [slashdot.org]

      • Yeah, RTFM yourself. OpenSSL.org is not a commercial site.

        I can sort-of understand not caching pages from commercial sites but from a site that is part of the "Open Source" community? The one that /. itself is also a big part of? It's inexcusable.
    • Well if most ISPs had some sort caching proxy, *and* managed to get their users to use it, this problem would be less severe, as the more a page is /.'ed, the more it's likely to generate a cache hit.

      The problem is that cacheing proxies are less and less used by ISPs nowadays as bandwidth is cheaper compared to the price of operating a proxy: cost of hardware, administration, fault tolerance etc. Big caches with lots of users are a lot of trouble; I guess it's however a good deal to implement them for medium/small sized networks, with at most a few thousand users.

      BTW I was thinking of a way to entice users to set up the proxy using traffic shaping and w/o using transparent proxy, which can be quite annoying at times: limit the bandwidth available on direct port 80 connections, but provide unlimited bandwidth through the proxy.
    • I've posted this rant before, but it seems appropriate to reiterate again in response to Slashdot killing the OpenSSL servers. As most people know, CmdrTaco gives a reason for not caching pages [slashdot.org] in the FAQ. Quotes from the FAQ answer:

      Sure, it's a great idea, but it has a lot of implications. For example, commercial sites rely on their banner ads to generate revenue. If I cache one of their pages, this will mess with their statistics, and mess with their banner ads. In other words, this will piss them off.

      Fair enough, and I agree - commerical sites probably would rather see the direct flow of visitors. However...

      Of course, most of the time, the commercial sites that actually have income from banner ads easily withstand the Slashdot Effect. So perhaps we could draw the line at sites that don't have ads. They are, after all, much more likely to buckle under the pressure of all those unexpected hits.

      Like OpenSSL - they are not commerical and cannot be expected to withstand the load of a Slashdotting and whatever other security lists have posted this.

      But what happens if I cache the site, and they update themselves? Once again, I'm transmitting data that I shouldn't be, only this time my cache is out of date!

      Well, yeah, that could be a problem. But then you get to:

      I could try asking permission, but do you want to wait 6 hours for a cool breaking story while we wait for permission to link someone?

      Well, yeah! I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update. It sure beats waiting a day for the Slashdot effect to have worn off and for the servers to be responsive again, or pissing off all the mirror operators who now can't get at the content they intend to mirror.

      Bottom line, I think contacting the owners of sites that probably cannot withstand the Slashdot Effect would be common courtesy - and possibly avoid some of the embarassments we've seen with Slashdot posting news of a release that hasn't actually happened.

      So while caching content may not be the best answer, at least contact the site operators. They might tell you to wait, or to use a mirror, or at least know that they can expect higher load for a while and can possibly reduce load on their end. It just seems like the smart and courteous thing to do.

      (And if anyone wants to question "a day" as for how long the Slashdot Effect lasts, yeah, I'm being overly drammatic. The Slashdot Effect generally lasts for around four hours on a site and then starts tappering off (with peak transfer from about 10 minutes after the link goes up to around 2 hours). Obviously, if there's a lot of data to transfer, the effect lasts longer. This is based on both the data transfer graphs generated with the Linux-powered Christmas tree and when I posted a mirror of KDE screenshots. Depending on the vitality of the content, like security updates, though, it's better to wait for the mirrors to get the content then to just send everyone looking all at once.)

      • I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update.
        Agreed. In fact, I seem to remember an offhand remark by one of the editors to the effect that they often queue stories to run at certain times of the day anyway (to give the community some time to discuss the current big story before the next one hits). If they're already delaying some stories for several hours or more, I see no reason why they couldn't also at least send a heads-up to the site admin.

        Of course, the flip side is this: the grandparent post suggested slashdot "pull a google". Why reinvent the wheel [google.com]? Why not just force editors to include links to the google cache whenever possible. Keep in mind that the cached page [216.239.39.100] will have a link to see the uncached version, so people who want to get up-to-date information can. If the focus of the story is images rather than text, include some links to the google cache of the images [google.com] (maybe below the fold if there's a lot of them, so they don't clutter up the main page).

        Taco & the gang have this attitude that there's nothing they can do about it. I disagree. It wouldn't even have to be that hard.

        Just my two and a half cents.

        • Why not just force editors to include links to the google cache whenever possible.
          Slashdot readers get something out of it. OpenSSL users get something out of it. And Google is left to pick up the check? What did they get out of it? I think this would be unfair to Google.
          • I disagree. Google is providing a service, and my suggestion would be to simply use that service as it is intended. Take a look: they actually encouage linking to cached versions of files.

            Certainly, if bandwidth became prohibitive, OSDN and Google could participate in some kind of joint-marketing project, with branded links ("click here for OpenSSL -- Powered by Google!") and/or advertising. I'd gladly put up with unobtrusive advertising in the google cache if it meant that I could get what I need to secure my system.

      • Well, yeah! I'd love to wait six hours to read a cool breaking story if it means I get to read the linked content or the mirrors have time to update. It sure beats waiting a day for the Slashdot effect to have worn off and for the servers to be responsive again, or pissing off all the mirror operators who now can't get at the content they intend to mirror.

        If this is how you feel, then just read stories on Slashdot when they're six hours old. Slashdottings don't really last that long, it's only the top stories that get clobbered. If you see something posted and can't get to it, relax, go get some coffee, play a round of pool (or do some sysadminning, if they actually make you work), then come back and get what you need when the rush has worn down a little.

        I understand you being concerned about security updates, but realistically, most security problems are in the wild before fixes are available anyway. System administration can't depend purely on getting the patch before the bad guy gets the exploit. Sooner or later that will fail.

        Personally, if there are people out there who know something I use is vulnerable, I want to know as soon as possible, rather than wait until I'm sure I can get the patch.

    • Everyone else has posted a link to the part of the faq where they explain why they don't cache, but there are some circumstances where it would be well worth it. This one for example. How many people right now are trying to download the update and can't get to the site. If you're not going to cache it, at least post the whole story, mirror the patch, or post the mirror list so the rest of us can get our security patches. I'm pretty sure you probably downloaded the patch for yourselves before you posted the story.

  • Bulletin (Score:2, Informative)

    by Anonymous Coward
    OpenSSL Security Advisory [30 July 2002]

    This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory.

    Advisory 1

    A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are conducting a security review of OpenSSL, under the DARPA program CHATS.

    Vulnerabilities

    All four of these are potentially remotely exploitable.

    1. The client master key in SSL2 could be oversized and overrun a buffer. This vulnerability was also independently discovered by consultants at Neohapsis (http://www.neohapsis.com/) who have also demonstrated that the vulerability is exploitable. Exploit code is NOT available at this time.

    2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.

    3. The master key supplied to an SSL3 server could be oversized and overrun a stack-based buffer. This issues only affects OpenSSL 0.9.7 before 0.9.7-beta3 with Kerberos enabled.

    4. Various buffers for ASCII representations of integers were too small on 64 bit platforms.

    The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0656 to issues 1-2, CAN-2002-0657 to issue 3, and CAN-2002-0655 to issue 4. In addition various potential buffer overflows not known to be exploitable have had assertions added to defend against them.

    Who is affected?

    Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is
    vulnerable, whether client or server. 0.9.6d servers on 32-bit systems with SSL 2.0 disabled are not vulnerable. SSLeay is probably also affected.

    Recommendations

    Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or
    TLS. A patch for 0.9.7 is available from the OpenSSL website (http://www.openssl.org/).

    Servers can disable SSL2, alternatively disable all applications using SSL or TLS until the patches are applied. Users of 0.9.7 pre-release
    versions with Kerberos enabled will also have to disable Kerberos. Client should be disabled altogether until the patches are applied.

    Known Exploits

    There are no know exploits available for these vulnerabilities. As noted above, Neohapsis have demonstrated internally that an exploit is
    possible, but have not released the exploit code.

    References

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CA N- 2002-0655
    http://cve.mitre.org/cgi-bin/cvename.cg i?name=CAN- 2002-0656
    http://cve.mitre.org/cgi-bin/cvename.cg i?name=CAN- 2002-0657

    Acknowledgements

    The project leading to this advisory is sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537. The patch and advisory were prepared by Ben Laurie.

    Advisory 2 Vulnerabilities

    The ASN1 parser can be confused by supplying it with certain invalid encodings. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0659 to this issue.

    Who is affected?

    Any OpenSSL program which uses the ASN1 library to parse untrusted data. This includes all SSL or TLS applications, those using S/MIME (PKCS#7) or certificate generation routines.

    Recommendations

    Apply the patch to OpenSSL, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL.
    Users of 0.9.7 pre-release versions should apply the patch or upgrade to 0.9.7-beta3 or later. Recompile all applications using OpenSSL.

    Exploits

    There are no known exploits for this vulnerability.

    References

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CA N- 2002-0659

    Acknowledgements

    This vulnerability was discovered by Adi Stav and James Yonan independently. The patch is partly
    based on a version by Adi Stav.

    The patch and advisory were prepared by Dr. Stephen Henson.

    Combined patches for OpenSSL 0.9.6d:
    http://www.openssl.org/news/patch_2002073 0_0_9_6d. txt

    Combined patches for OpenSSL 0.9.7 beta 2:http://www.openssl.org/news/patch_20020730_0_9_7 .txt

    URL for this Security Advisory: http://www.openssl.org/news/secadv_20020730.txt

  • Security Advisory from Bugtraq (Score:3, Informative)

    by Anonymous Coward on Tuesday July 30, 2002 @10:30AM (#3977832)
    The original security advisory (with attached patch for OpenSSL 0.9.6d) is here [securityfocus.com]. A follow-up with patches for older versions is here [securityfocus.com].

  • Advisory + Patch (Score:4, Informative)

    by ChiefArcher ( 1753 ) on Tuesday July 30, 2002 @10:36AM (#3977870) Homepage Journal
    http://online.securityfocus.com/archive/1/285022/2 002-07-27/2002-08-02/0

  • Argh. (Score:1)

    by BJH ( 11355 )

    Red Hat's servers are /.ed and I'm getting 5KB/s in up2date.

    Great, just great...

  • Advisory Mirror (Score:3, Informative)

    by ActMatrix ( 246577 ) on Tuesday July 30, 2002 @10:37AM (#3977875) Homepage
    Here's a copy of the full advisory [hideaway.net] since the OpenSSL site is /.'d.
  • Here's [umich.edu] the text of the advisory.

    :w

    • Perhaps I'm mistaken, it having been awhile since I learned my alphabet but is it not so that C comes before D? And the suggested action is to patch D or upgrade to E?

      Unless some funky patching is going on, let's link to a deb that is actually not vulnerable here ok?

      • Re:Debian users: (Score:3, Informative)

        by CentrX ( 50629 )
        For stable releases, Debian backports the patches to the version that's in stable, so as not to introduce problems that may result from introducing a relatively heavily modified new release. That's why it's called "stable". From the Debian Security Advisory: "These vulnerabilities have been addressed for Debian 3.0 (woody) in openssl094_0.9.4-6.woody.0, openssl095_0.9.5a-6.woody.0 and openssl_0.9.6c-2.woody.0." So, the link provided is a package that isn't vulnerable.

      • Re:Debian users: (Score:2, Informative)

        by BJH ( 11355 )
        Debian doesn't generally upgrade the software in question to a later external version unless it's absolutely necessary - instead, they patch the version that they know is stable and move their internal version up a notch.
      • In general, this isn't valid -- Debian stable is supposed to be very stable, and so when an exploit is found in a Debian package, they'll patch only that bug instead of upgrading to the "minimum safe" version (which might break something else.)
        So yes, some "funky patching" is going on :-).
      • This really pisses me off since your username is close to mine. Your sig works out obviously to the string "cat /etc/passwd|mail Guest" which is then executed as a shell command, sending an insecure password file to some supposedly insecure mail account. (No I didn't execute it, and I run shadowed. Duh.)

        I wonder if you are the same matts as on perlmonks.org. I am the same mattr. How annoying.

        I'll thank you to remove that sig. Now, please. It's not funny to lay a pipe bomb and a box of matches on the curb; some people have a death wish and you are just helping them along.
        • Heh, one word describes you my friend, and that word is "git"

          1. My sig mails you your own passwd file. Were you even in 'first grade perl' you could figure that out. Maybe you can actually read Perlmonks instead of just being a groupie there. It makes a point that idiots like you shouldn't blindly exec perl one-lineers off slashdot sigs. See my profile for an actual nasty version and more info.

          2. If your english skills are soo poor that you can't differentiate from "Mr_Perl" and "mattr" I really wonder how you managed those 3 paragraphs.
          • A. Idiot. I didn't execute it, as I said. And the post I saw was signed "matts" who is on Perlmonks, not "Mr_Perl". Conceivably I could have seen his name on a post above or below yours, and not yours by accident. But thanks for owning up to it, "Mr. Perl". I do Perl programming for a living and am not half bad at it, what's your excuse? Silly kiddie.

            B. It didn't require too much sweat to discover your lame-ass justification for your stupid (and criminal FWIW) sig. As it is there is little danger of anyone executing your sig, and all I have to do is wait a couple years or more until you get older and some similar stupidity blows up magnificently in your pinched egotistical face. Have a nice life (unlikely).

    • Sid package is also on incominig.debian.org or you can grab it from
      http://mordikyn.dynu.com/openssl_0.9.6e-1_i3 86.deb

  • Slashdot is hilarious (Score:1, Funny)

    by Anonymous Coward
    When Internet Explorer or IIS has a bug, it's a security "vulnerability" or "exploit". When Mozilla or OpenSSH has a bug, it's a security "update". I love how Slashdot doesn't even bother to hide its shameless bigotry and complete lack of journalistic integrity. Rob Malda and the janitors are morons of the stupidest caliber.

    -- The_Messenger
    (Banned for telling the truth.)

  • Mirrors (Score:5, Informative)

    by Wouter Van Hemel ( 411877 ) on Tuesday July 30, 2002 @10:51AM (#3977945) Homepage
    Damn /. morons, was it really necessary to link to the _main_ site instead of providing some mirrors?

    Most mirrors are not up to date yet, except:

    ftp://opensores.thebunker.net/pub/mirrors/openss l/ source/
    ftp://ftp.psy.uq.edu.au/pub/Crypto/OpenSS L/
    ftp://ftp.infoscience.co.jp/pub/Crypto/SSL/ope nssl /source/
    ... but by the time you read this, maybe the others have it too (thanks to google... yet again):

    * ftp://ftp.openssl.org/source/ [CH]
    * ftp://sunsite.cnlab-switch.ch/mirror/openssl/ [CH]
    * ftp://ftp.funet.fi/pub/crypt/cryptography/libs/ope nssl/ [FI]
    * ftp://ftp.pca.dfn.de/pub/tools/net/openssl/ [DE]
    * ftp://ftp.ecrc.net/pub/security/openssl/ [DE]
    * ftp://ftp.uni-trier.de/pub/unix/security/openssl/ [DE]
    * ftp://ftp.webmonster.de/pub/openssl/ [DE]
    * ftp://opensores.thebunker.net/pub/mirrors/openssl/ [UK]
    * ftp://ftp.net.lut.ac.uk/openssl/ [UK]
    * ftp://ftp.mirror.ac.uk/sites/ftp.openssl.org/ [UK]
    * ftp://sunsite.uio.no/pub/security/openssl/ [NO]
    * ftp://ftp.sunet.se/pub/security/tools/net/openssl/ [SE]
    * ftp://ftp.chl.chalmers.se/pub/unix/security/openss l/ [SE]
    * ftp://ftp.psy.uq.edu.au/pub/Crypto/ [AU]
    * ftp://mirror.aarnet.edu.au/pub/openssl/ [AU]
    * ftp://gd.tuwien.ac.at/infosys/security/openssl/ [AT]
    * ftp://glock.missouri.edu/pub/openssl/ [US]
    * ftp://ftp.av8.com/pub/mirrors/openssl/ [US]
    * ftp://ftp.styx.net/mirrors/crypto/openssl/ [US]
    * ftp://gw.inetlab.com/mirrors/openssl/ [RU]
    * ftp://ftp.mos.net/pub/security/openssl/ [RU]
    * ftp://ftp.ebizlab.hit.bme.hu/pub/openssl/ [HU]
    * ftp://ftp.kfki.hu/pub/packages/security/openssl/ [HU]
    * ftp://guest.kuria.katowice.pl/pub/openssl/ [PL]
    * ftp://ftp.win.ne.jp/pub/network/security/openssl/ [JP]
    * ftp://ftp.infoscience.co.jp/pub/Crypto/SSL/openssl / [JP]
    * ftp://ftp.happysize.co.jp/mirror/openssl/ [JP]
    * ftp://ftp.ncu.edu.tw/Unix/Crypto/OpenSSL/ [TW]
    * ftp://ftp.mit.com.tw/pub/SSL/openssl/ [TW]
    * ftp://ftp.elab.co.za/support/openssl/source/ [ZA]
    * ftp://ftp.fisek.com.tr/pub/openssl/ [TR]
    * ftp://ftp.fi.muni.cz/pub/openssl/ [CZ]
    * ftp://ftp.sunsite.utk.edu/pub/openssl/ [US]
    * ftp://ftp.gm.is/pub/openssl/ [IS]
    * ftp://ftp.directnet.ru/pub/openssl/ [RU]
    * ftp://ftp.linux.hr/pub/openssl/ [HR]
    * ftp://ftp.1stnet.co.uk/pub/mirrors/openssl/ [UK]
    * ftp://mirror.aarnet.edu.au/pub/openssl/ [AU]
    * ftp://storm.alert.sk/mirrors/openssl/ [SK]
    * ftp://ftp.openssl.uli.it/ [IT]
    * ftp://ftp.grmbl.com/pub/openssl/ [BE]
    * ftp://ftp.gin.cz/pub/MIRRORS/ftp.openssl.org/ [CZ]
    * ftp://ftp.calyx.nl/pub/openssl/ [NL]
    * ftp://ftp.duth.gr/pub/OpenSSL/ [GR]
    * ftp://ftp.linux.gr/pub/crypto/openssl/ [GR]
    * ftp://ftp.si.uniovi.es/mirror/OpenSSL/ [ES]
    Cheers.
  • Don't you think it's unfair that slashdot doesn't make a local mirror, or at least a local copy of files like this one? For people that pay by the megabyte being slashdotted is not only annoying, but costs them money. On one hand it would be cool to get that much attention, but most of the articles are not posted by people related to a linked site. The poor admin that has to get up early in the morning to fight what looks like a DDOS, but is in fact the slashdot effect.
    • I agree; while I realize that Slashdot also pays for bandwidth, they're far better equipped to handle the millions of visitors who would be looking for this information. I wouldn't expect you to host a copy of the openssl source, but you could at least mirror the notice that there's a vulnerability. Especially when the submitter's writeup is completely devoid of content relating to the problem, like Pseud0's was this time. Really, you are doing a disservice to the community.

      Obviously if you link to nytimes.com or cnet.com they're equipped to handle millions of visitors, but openssl.org? I doubt it very much.

  • GNU TLS (Score:2, Interesting)

    by cras ( 91254 )

    GNU TLS [gnu.org] is finally beginning to be usable. It even has wrapper for OpenSSL API providing source code compatibility for it.

    I just today started looking into it more deeply as I'll need to implement SSL and TLS support fo my imapd [procontrol.fi]. The documentation and example programs with gnutls are quite good. And given that the next thing I read after the docs is OpenSSL vulnerability, I'm pretty sure I'll just use gnutls API directly.

  • No signature on the bulletin to Bugraq (Score:4, Interesting)

    by realdpk ( 116490 ) on Tuesday July 30, 2002 @12:00PM (#3978495) Homepage Journal
    Do we know this is a real, legitimate problem? I can't get to www.openssl.org to see, but the bulletin that went out had no authenticator. The link to a list of mirrors someone posted doesn't contain any valid mirrors, except its own. (That is, it looks like they have a series of links to FTP sites that do not allow anonymous access, except for a site on their own network. Highly suspicious.)
    • Here [redhat.com].

      This is the first place I looked this morning (as I run several RH7.2 servers). The discussion there seems to be fairly similar to the copies of the advisory I've seen posted here, so I'd be willing to bet it's legit.

  • Upgrading SSL is nothing like upgrading SSH (Score:5, Interesting)

    by tzanger ( 1575 ) on Tuesday July 30, 2002 @12:07PM (#3978586) Homepage

    I have 18 firewalls to update (I sell these and support them, it's a nice way to suppliment my income). I'm not having much luck updating them though.

    So far (on 5/7 firewalls), updating the ssl libraries caused ssh to kick out. This is very much unlike upgrading ssh, where the currently running sessions would stay active and you just kill off the 'parent' sshd process and restart sshd to upgrade.

    Does anyone know why upgrading the shared lib is kicking out running sessions of ssh linked against it? Short of compiling sshd statically, is there any way around this? So far all the boxes are local but I have a few that are quite a distance and short of enabling telnet with a throwaway root account or statically compiling a temporary sshd, I'm screwed. :-)

  • From the bugtraq announcement:

    Package : openssl
    Problem type : multiple remote exploits
    Debian-specific: no
    CVE : CAN-2002-0655 CAN-2002-0656 CAN-2002-0657 CAN-2002-0659

    The OpenSSL development team has announced that a security audit by A.L.
    Digital Ltd and The Bunker, under the DARPA CHATS program, has revealed
    remotely exploitable buffer overflow conditions in the OpenSSL code.
    Additionaly, the ASN1 parser in OpenSSL has a potential DoS attack
    independently discovered by Adi Stav and James Yonan.

    CAN-2002-0655 references overflows in buffers used to hold ASCII
    representations of integers on 64 bit platforms. CAN-2002-0656
    references buffer overflows in the SSL2 server implementation (by
    sending an invalid key to the server) and the SSL3 client implementation
    (by sending a large session id to the client). The SSL2 issue was also
    noticed by Neohapsis, who have privately demonstrated exploit code for
    this issue. CAN-2002-0659 references the ASN1 parser DoS issue.

    These vulnerabilities have been addressed for Debian 3.0 (woody) in
    openssl094_0.9.4-6.woody.0, openssl095_0.9.5a-6.woody.0 and
    openssl_0.9.6c-2.woody.0.

    These vulnerabilities are also present in Debian 2.2 (potato), but no
    fix is available at this moment.

    We recommend you upgrade your OpenSSL as soon as possible. Note that you
    should restart any daemons running SSL. (E.g., ssh or ssl-enabled
    apache.)
  • Patches also available in http://www.ademar.org/misc/openssl-patches for the ones who haven't access to bugtraq or openssl-{devel,users}.

    Date: Tue, 30 Jul 2002 14:42:12 -0300
    From: "Ademar de Souza Reis Jr." <ademar@conectiva.com.br>
    Subject: Re: OpenSSL patches for other versions
    To: Bugtraq <BUGTRAQ@SECURITYFOCUS.COM>
    Cc: Ben Laurie <ben@algroup.co.uk>,
    OpenSSL Announce <openssl-announce@openssl.org>,
    OpenSSL Dev <openssl-dev@openssl.org>, openssl-users@openssl.org
    X-Url: http://www.ademar.org/

    [-- Attachment #1 --]
    [-- Type: text/plain, Encoding: 7bit, Size: 1.0K --]

    On Tue, Jul 30, 2002 at 11:15:00AM +0100, Ben Laurie wrote:
    > Enclosed are patches for today's OpenSSL security alert which apply to
    > other versions. The patch for 0.9.7 is supplied by Ben Laurie
    > <ben@algroup.co.uk> and the remainder by Vincent Danen (email not
    > supplied).
    >
    > Patches are for 0.9.5a, 0.9.6 (use 0.9.6b patch), 0.9.6b, 0.9.6c, 0.9.7-dev.
    >
    > These patches are known to apply correctly but have not been
    > thoroughly tested.

    Hello.

    While checking the patches you sent I noticed that in the ones for
    openssh < 0.9.7-dev, the ASN.1 fix is not present (several checks in
    crypto/asn1/asn1_lib.c).

    So I backported the fixes based on 0.9.7-dev and in a patch for 0.9.6d sent
    by Ben Laurie to openssl-team@openssl.org on July27 (subject: Final
    version?).

    Patches for 0.9.5a, 0.9.6a and 0.9.6b including fix for ASN.1 vulns attached.
    They're not well tested yet - after sucessful compilation.

    Cheers.
    - Ademar
  • To all the people who said I was being too paranoid in running statically-linked 'stunnel' chrooted to an otherwise empty (no /bin/sh, etc) subdirectory, containing only the client public keys...

    I told you so.

    To the guy who said that my running SSHd behind stunnel to protect from SSH bugs (such as the recent OpenSSH advisory) was not paranoid enough:

    You were right, I wasn't paranoid enough

    Time to wrap everything in IPSEC, then wait for a new hole in that?

  • openssl-0.9.6e (unlike d) goes through an almost endless sequence of refusing to install its man pages because it doesn't like the way the Perl 5.6.1 (also known as "stable") runs its Pod::Man module. Does anyone have a workaround that doesn't involve installing Perl 5.8.0 (not yet promoted to "stable" by the Perl folks)? Heck, does that even work, or are the openssl folks trying to force a downgrade of Perl? CPAN doesn't offer an obvious solution.

    I don't really imagine we need the man pages, but putting a dependency like this in the openssl source is thoughtless - right when we're trying to have confidence in the crew there.
    ___

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close