OpenSSL Security Update

Mirrors list mirrored by Olinator · 2002-07-30 02:11 · Score: 5, Informative

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

--
Need a UNIX/Linux/network guru in the Boulde

Question by Ender+Ryan · 2002-07-30 02:14 · Score: 3, Interesting

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

--
Sticking feathers up your butt does not make you a chicken - Tyler Durden

How about some common courtesy? by gosand · 2002-07-30 02:15 · Score: 5, Insightful

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.

--

My beliefs do not require that you agree with them.

Re:How about some common courtesy? by tbmaddux · 2002-07-30 02:26 · Score: 5, Informative

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.

--
Can't you see that everyone is buying station wagons?
Re: How about some common courtesy? by Black+Parrot · 2002-07-30 03:31 · Score: 3, Insightful

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

--
Sheesh, evil *and* a jerk. -- Jade
Re:How about some common courtesy? by krogoth · 2002-07-30 07:42 · Score: 3, Informative

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.

--

They that quote Benjamin Franklin on liberty and safety deserve neither.

Answer by petard · 2002-07-30 02:16 · Score: 5, Informative

engine versions incorporate support for hardware cryptographic devices.

--
.sig: file not found

The Slashdot effect - enough is enough by pieterh · 2002-07-30 02:18 · Score: 4, Insightful

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.

--
My blog

Re:The Slashdot effect - enough is enough by _xeno_ · 2002-07-30 03:34 · Score: 3, Insightful

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

--
You are in a maze of twisty little relative jumps, all alike.
Re:The Slashdot effect - enough is enough by realdpk · 2002-07-30 03:57 · Score: 3, Insightful

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.

Happy Xmas by fingal · 2002-07-30 02:30 · Score: 5, Informative

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.

--

The only Good System is a Sound System

Security Advisory from Bugtraq by Anonymous Coward · 2002-07-30 02:30 · Score: 3, Informative

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 by ChiefArcher · 2002-07-30 02:36 · Score: 4, Informative

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

Advisory Mirror by ActMatrix · 2002-07-30 02:37 · Score: 3, Informative

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

Re:Logic behind this by spudnic · 2002-07-30 02:47 · Score: 5, Informative

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.

--
load "linux",8,1

Mirrors by Wouter+Van+Hemel · 2002-07-30 02:51 · Score: 5, Informative

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:OK. I admit I'm biting by mborland · 2002-07-30 03:37 · Score: 3, Insightful

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:Debian users: by Mr_Perl · 2002-07-30 03:37 · Score: 3, Funny

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?

--

My poetry site welcomes the unusual.

Re:Debian users: by CentrX · 2002-07-30 03:44 · Score: 3, Informative

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.

--

"The price of freedom is eternal vigilance." - Thomas Jefferson

Re: another victory for Open Source! by Black+Parrot · 2002-07-30 03:49 · Score: 3, Informative

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

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

--
Sheesh, evil *and* a jerk. -- Jade

Upgrading SSL is nothing like upgrading SSH by tzanger · 2002-07-30 04:07 · Score: 5, Interesting

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

21 of 208 comments (clear)