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)

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?

[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?

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

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

[_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

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

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

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