OpenSSL Security Update

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

Comments

Logic behind this

[Your_Mom]

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)

Re:Logic behind this

[phaxkolumbo]

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.

Re:Logic behind this

[Your_Mom]

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)

Re:Logic behind this

[spudnic]

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.

Re:Logic behind this

[LiquidPC]

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.

Re:Logic behind this

[realdpk]

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

[Olinator]

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

Re:Mirrors list mirrored

[Olinator]

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

Re:Mirrors list mirrored

[dsaljurator]

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

[Ender Ryan]

What is the difference between openssl-engine-0.9.6e.tar.gz and openssl-0.9.6e.tar.gz?

How about some common courtesy?

[gosand]

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?

[tbmaddux]

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.

Re: How about some common courtesy?

[Black Parrot]

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

Re: How about some common courtesy?

[realdpk]

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.

Re: How about some common courtesy?

[hobit]

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.

Re:How about some common courtesy?

[krogoth]

If you care about security, you should be reading Bugtraq. 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.

Re: How about some common courtesy?

[Black Parrot]

> bugs exist. deal with it. expecting anything less is naive.

That's exactly the attitude that baffles me. Sure bugs exist... but why not eliminate the ones that are easy to eliminate?

Especially something as déclassé as a buffer overflow in "secure" networking infrastructure?

> to rewriting these in 'safe' languages. thank you very much but no.

The issue I wanted to raise isn't a suggestion for a re-write, but rather, why wasn't it done right in the first place? This could have been prevented easily, either by choice of language or use of alternative I/O routines.

> pushing the responsibity for security off the software author and onto the compiler/virtual machine is not a solution. it just deflects blame.

That's a curious excuse^w attitude.

> not to mention the performance implications of doing crypto in a virtual machine. blech

I certainly didn't have Java in mind. There are plenty of ways of avoiding this problem without resort to a virtual machine.

Re: How about some common courtesy?

[Black Parrot]

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

Re:How about some common courtesy?

[gosand]

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.

Answer

[petard]

engine versions incorporate support for hardware cryptographic devices.

The Slashdot effect - enough is enough

[pieterh]

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.

Re:The Slashdot effect - enough is enough

[Anonymous Coward]

RTFM: Why Slashdot doesn't cache

Re:The Slashdot effect - enough is enough

[Nicolas MONNET]

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.

Re:The Slashdot effect - enough is enough

[_xeno_]

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

Re:The Slashdot effect - enough is enough

[liquidsin]

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.

Re:The Slashdot effect - enough is enough

[realdpk]

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.

Re:The Slashdot effect - enough is enough

[Da Schmiz]

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? Why not just force editors to include links to the google cache whenever possible. Keep in mind that the cached page 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 (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.

Re:The Slashdot effect - enough is enough

[Sloppy]

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.

Re:The Slashdot effect - enough is enough

[Da Schmiz]

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.

Re:The Slashdot effect - enough is enough

[zCyl]

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.

Bulletin

[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

Happy Xmas

[fingal]

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.

Re:Happy Xmas

[fingal]

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 to their archive of the mail (including patch). Enjoy...

Security Advisory from Bugtraq

[Anonymous Coward]

The original security advisory (with attached patch for OpenSSL 0.9.6d) is here. A follow-up with patches for older versions is here.

Advisory + Patch

[ChiefArcher]

http://online.securityfocus.com/archive/1/285022/2 002-07-27/2002-08-02/0

Advisory Mirror

[ActMatrix]

Here's a copy of the full advisory since the OpenSSL site is /.'d.

Re:Security is a Fallacy

[DLR]

So, just because it's easy to pick a lock means I shouldn't have locks on my car, home, etc.? No, there is an entire hierarchy of locks, some more difficult to pick than others. The question is how much do you want to pay for your locks? A pin tumbler (aka cylinder lock) is inexpensive, fairly easy to pick (so I hear) and what almost everyone in the USA has on the door of their dwelling. Wafer tumblers are even easier to pick, but that's what protects your car. Why use them since they're so insecure? Because they do the job 99% of the time.

So do a cost/benefit analysis, are you better off NOT using SSH/SSL et. al. or does it make sense to use them? Take a look at the history of what you are discussing. I don't believe that SSL has ever been cracked "in the wild". All of the Internet credit card theft I am aware of has been from the server being rooted and access to the data obtained, never through intercepting it en route.

DLR

Debian users:

[xercist]

http://incoming.debian.org/openssl_0.9.6c-2.woody. 0_i386.deb

Ahh, how I love debian

Re:Debian users:

[Mr_Perl]

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:

[CentrX]

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:

[BJH]

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.

Re:Debian users:

[Mr_Perl]

Thanks for the clarification, mod parent up someone =)

Re:Debian users:

[Tadghe]

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

Re:Debian users:

[Chops]

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

Re:Look in alt.binaries.warez.linux in 15 minutes

[mr_z_beeblebrox]

I'll put them there. Quit hammering their servers.

Don't worry about that pesky /. affect sir. I got the binary patch off a warez server. All secure now ;-)

Re:Security is a Fallacy

[Flower]

No, security is a process.

Mirrors

[Wouter Van Hemel]

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.

Re:buffer overrun != cracked encryption

[roachmotel3]

Ahh -- but that's not CRACKING encryption. That's working from within the boundaries of the system to achieve a goal. Cracking OpenSSL would be like cracking WEP -- if you give me enough data, I could crack the key and start decrypting traffic. This is VERY different.

The point is that the actual method of encryption itself, the mathematical formulas and principles, are still very valid and relevent. It just means that you can't leave the backdoor unlocked.

Agreed - please mirror contents

[Evro]

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.

Re:buffer overrun != cracked encryption

[mr_z_beeblebrox]

It just means that you can't leave the backdoor unlocked.

Righto, but unchecked buffers are a backdoor that most won't notice. Unfortunately many OSS software developers harp about them being easy to find in a good code audit. I think the OpenSSL people got a little to carried away in implemting their encryption strategy and didn't focus on the basics.

However, if M$ ever comes up with a better product it will doubtless say BSD in the comments.

Re:OK. I admit I'm biting

[Enry]

>Doesn't OpenSSH rely on OpenSSL to function?

No.

Yes it does. But I don't think any of the vulernabilities that affect OSSL will affect OSSH.

Re:OK. I admit I'm biting

[mborland]

Doesn't OpenSSH rely on OpenSSL to function?

No.

Really? I need it for the install of SSH, and ssh -V indicates the version of OpenSSL used. Maybe you mean that OpenSSH is not vulnerable due to the way it uses the libraries.

A little clarification might be useful.

Re: another victory for Open Source!

[Black Parrot]

> Thanks to "many eyes," no sooner is a flaw detected than it is patched up!

<pedantic>Actually, "many eyes" didn't have much to do with either facet, this time. The detection was done by the (presumably pay-to-view) eyes at A.L. Digital Ltd and The Bunker, and the fix isn't an "eyes" issue at all, but rather a get-on-the-ball-and-do-it issue.</pedantic>

But you're entirely right about the quick turn-around. The good folk at OpenSSH completely skipped the Six Step Security Patch Development Cycle so commonly used in the commercial software world thes days:

1. deny it, as long as possible
2. promise an investigation, as long as possible
3. promise "real soon now", as long as possible
4. make excuses for the delay, as long as possible
5. release a broken fix, investing as little effort as possible
6. GOTO 1

Upgrading SSL is nothing like upgrading SSH

[tzanger]

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

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

Odd, I just updated ssl remotely via an ssh connection (compiled against the previous libs). I then recompiled ssh without problem.

Like I said, 5/7 boxes failed to do this nicely. Two of them worked as I had thought they should -- yes the libs change underneath you but you're running from in-memory copies. Someone told me this variation was due to glibc but I haven't found anything conclusive.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

The deal is that the version of SSH may not support the API OpenSSL provides in the latest patched version. You may have to wait for SSH to be updated to work with the newest one.

Interesting theory but why would a simple recompile of ssh work then? If the API changed I would have thought to see compiler errors.

Re:Upgrading SSL is nothing like upgrading SSH

[Dimensio]

I found something.

I was updating two of my boxes from home while at work. I ssh into one box from work and from that ssh session I ssh into the other box (due to firewall configuration).

On the "main" box -- the one to which I go in from work -- updating openssl was smooth and efficient, as was updating ssh. Download source, compile and go.

On the "workstation" box -- the one I go in from the main box -- I had a problem when trying to run the configure script for openssh after compiling openssl. Turns out that it is looking for a shared libssl rather than a static one! I don't know why this happened (both machines use openssh source from the same tarball!), but I recompiled openssl with shared support enabled, and the connection dropped as soon as I tried to install.

Openssh shouldn't be using shared openssl libs (in fact, nothing should use shared openssl libs according to the readme), so I suspect I'll need to check that when I recompile it. I know that the ssh compile on my "main" box isn't using shared libs because I have no libssl.so, only libssl.a. I suspect that the presence of an existing shared openssl library ($#@$ing default install) triggered a detection in the configure script.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

I think you found the reason why. Interesting, and thanks for sharing the info.

The OpenSSL INSTALL file doesn't exressly forbid shared libraries, just that they're experimental. I think I've learned my lesson though; static ssl libs for me. :-)

... I wonder why I was ever building OpenSSL with shared libaries - something tells me that mod_ssl for Apache required shared libs but in reading over its README and INSTALL files I can't find it there. <shrut>

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

A workaround would be to move the existing library aside before you do make install. (e.g. mv libssl.so.0.9.6 libssl.so.0.9.6-OLD)

I've noted that for future reference. :-) Offhand, do you know if glibc/gcc does this automatically when you install updated system libraries? I don't ever recall this happenning with those libraries.

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

make install && /sbin/ldconfig && /etc/init.d/sshd restart

That's exactly what I did for the remainder of the installs but I used nohup instead. Same effect.

Funny, but the rest of the systems didn't crash out anyway. Unreal. :-)

Re:Upgrading SSL is nothing like upgrading SSH

[tzanger]

Try copying the shared SSL library to another location, then start a new sshd on a different port using LD_LIBRARY_PRELOAD.

That would have been the quick way to do it. :-) I ended up using an idea very much like vph's to solve it. Thanks for the idea though, I'll keep that stored away because I'm sure it'll be handy elsewhere.

How does this impact OpenSSH?

[emil]

I'm running OpenSSH 3.4p1 on:

• Red Hat Linux 6.2 with Privilege Separation active,
• HP-UX 10.20 and 11 without Privilege Separation.

Do I need to rebuild these binaries? When will the OpenSSL audit be complete?

Re:How does this impact OpenSSH?

[0xA]

I _think_ they are linked, also someone else mentioned that if you update openssl while OpenSSH is running it will hang.

That would seem to support the linked idea. Don't bet on it though.

Details from the Debian Security Advisory...

[illsorted]

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

What, are you stupid?

[AilleCat]

Anyone who thinks they can secure thier box by getting a binary patch from this joker is inviting a nice backdoor/trojan.

Calmly proceed to nearest mirror, FreeBSD users, calmly wait for nectar to import it, other OS's wait for packages, or for itto be imported.

Rushing out in panic is not helping you.

Patches for old versions

[asr_br]

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

Re:Look in alt.binaries.warez.linux in 15 minutes

[zCyl]

It is unlikely that anyone could get the same MD5 sum

If warez folk developed magic powers to undo one-way functions, the world would have much bigger problems than the security of your server.

Once again, paranoia pays off.

[Nonesuch]

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?

pod2man in Perl 5.6.1 rejected in openssl install

[wytcld]

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

Older makefile code avoids the problem

[wytcld]

Replacing the install_docs part of the Makefile with the version from 0.9.6c fixes the problem. I'd quote it here but that violates /.'s "postercomment" compression filter. Anyway, it installs the docs just fine.
___

On the upside...

[Goonie]

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.

BASTARD! Thanks for your fucking criminal sig.

[mattr]

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.

Re:vulnerable if you just use it for ssh?

[hearingaid]

Thanks; mod parent up, folks.

And another thing. If you upgrade your OpenSSL, do you then need to recompile OpenSSH to link to the new libraries?

Re:[expl]! Thanks for your [expl] criminal sig.

[Mr_Perl]

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.

Re:[expl]! Thanks for your [expl] criminal sig.

[mattr]

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