Slashdot Mirror
Major OpenSSL Security Issue Found (and Fixed)
tearmeapart writes "A major security issue has been found in all OpenSSL packages. You probably want to download your preferred OpenSSL package as soon as possible. Changes to the CVS repository are detailed on the OpenSSL timeline."
"Only" a problem for systems where size_t is different from int. So the 15% of you still running in a 32 bit world can rest easy. This also means that on a mixed 32/64 bit system, you could use 32bit libraries until you get around to patching everything. Remember, a whole bunch of stuff uses ssl. Have fun fixing your Java jars.
Is this a remote exploit?
Yes.
Does this mean my client can be overrun if a server throws me a bad packet or two?
Yes.
I guess my other question is, how can the most utilized utility on a system still have unchecked overflows?
Have you ever looked at the OpenSSL code? It could have the Ark of the Covenant hidden in all that mess somewhere for all we know and we'd never find it.
Truly, the OpenSSL code is quite hideous. I mean, from what I saw they basically wrap calls to realloc and that was part of the problem because they did it half-assedly.
But even the API is a horrible nightmare to use and documentation is scant. Sure you can find a billion *examples* that have all copied from the examples given in the source distribution (which were third-party contributed) but actually finding out what's necessary or important is almost impossible from the documentation. You literally have to either copy the (pretty much undocumented) example, or roll your own and hope for the best.
I wrote some code using OpenSSL a while back to verify two PEM certificates (one signing the other). God, was that a trek through uncharted territory. In the end, I just made a "broken" certificate chain with fake / broken certificates in every way I could imagine and just kept testing my code until I'd taken account of every problem with the certs that I could reasonably generate myself. Even getting the plain certificate name out of certificate can be an exercise in guesswork.
I'm not at all surprised, to be honest. And that it was something as simple and obvious (and hidden behind deliberate casts that would stop the compiler warnings) is hardly a shock, once you've tried to plough through their code.
That's one reason OpenSSH has been moving towards more restricted/careful use of OpenSSL, and I believe in this case it actually makes OpenSSH not vulnerable, because this is (yet another) bug in the ASN.1 parser, and OpenSSH doesn't use the OpenSSL ASN.1 parser anymore. Sometime a few years ago they replaced it with a minimal, special-cased, audited internal version, which can't handle full ASN.1, but can handle the subset used in OpenSSH. See section 3.2 of this paper (pdf) for a bit more.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Are you sure about that?
The advisory says that SSL/TLS code is not affected, and only software that parses ASN.1/DER structures from BIO or FILE streams could be impacted. Parsing ASN.1 from memory is also not affected. That would appear to restrict the vulnerable software quite a bit.
Whether you have a remote vulnerability or not would seem to depend very highly on what software you're running.
I guess my other question is, how can the most utilized utility on a system still have unchecked overflows?
Have you ever looked at the OpenSSL code? It could have the Ark of the Covenant hidden in all that mess somewhere for all we know and we'd never find it.
No kidding. I've seen a lot of horrible messes in my career, but OpenSSL tops them all. There have to be hundreds of serious security bugs lurking in there... the only thing saving us is that it's so nasty not even the black hats want to dig in there to find them. Good security code should be as simple and straightforward as possible, to make it easy to verify. The authors of OpenSSL took a... different approach.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
"because this is (yet another) bug in the ASN.1 parser"
This is because ASN.1 is an insanely complex, wasteful and redundant standard that should have never been adopted for security related standards where simplicity is an important contributor to writing secure code.
ASN.1 has been the bane of all the standards that ever adopted it (SNMP anyone?) and should have been shot years ago.
it's good enough that so far nobody's thought it's worth the effort to write a new SSL library from scratch.
Except for GNU's gnutls, but they did it because their only problem with openssl it is that it's BSD licensed.
If I have been able to see further than others, it is because I bought a pair of binoculars.
But, it's good enough that so far nobody's thought it's worth the effort to write a new SSL library from scratch.
Err, yes, apart from GnuTLS, Mozilla's NSS, Gutmann's cryptlib, yaSSL (there's enough to name one yet another ...), Polar SSL, and probably more -- and that's only counting C libraries available under an open source license.
The latest OpenSSL has problems connecting to facebook.com and paypal.com
Sounds like a feature, not a bug.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!