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