Major OpenSSL Security Issue Found (and Fixed) 78
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."
It only affects 64 bit systems (Score:5, Informative)
Re:Anyone want to translate this into dummy speak? (Score:5, Informative)
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.
Re:It only affects 64 bit systems (Score:4, Informative)
Yet another reason you why you fuckerlords who ignore standards and types like size_t and intptr_t need to choke.
Re:Anyone want to translate this into dummy speak? (Score:5, Informative)
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.
Re:Anyone want to translate this into dummy speak? (Score:5, Informative)
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) [openbsd.org] for a bit more.
Re:Security issue how? (Score:4, Informative)
If you handle on-disk certificates using a program (e.g. Apache, which reads them from /etc/ssl), there's a potential for arbitrary code execution (literally, the attacker writing what they want to the heap).
Now think about browser's cached certificates, or a browser that might write them to disk and then read them from there rather than the network, or utilities that "do things" with PEM certificates, or basically anything that uses SSL with an on-disk certificate that could come from a malicious source.
No, your browser's SSL session is probably still quite safe, but it's far from being a non-issue from a security standpoint.
Re:Anyone want to translate this into dummy speak? (Score:5, Informative)
Are you sure about that?
The advisory [openssl.org] 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.
Re:Security issue how? (Score:4, Informative)
From TFA:
"The old data is always copied over, regardless of whether the new size will be
enough. This allows us to turn this truncation into what is effectively:
memcpy(heap_buffer, , );"
Letting the attacker write to arbitrary/unexpected memory is always a security issue... [I guess it might not be easily exploitable in all cases based on system setup/random memory allocation, etc though]
Re:Anyone want to translate this into dummy speak? (Score:5, Informative)
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.
Security vs functionality (Score:3, Informative)
> You probably want to download your preferred OpenSSL package as soon as possible
No, you don't. The latest OpenSSL has problems connecting to facebook.com and paypal.com (they filter Client Hello packets larger than 255 bytes, and, unfortunately, OpenSSL creates those). Please see http://bugs.debian.org/665452
Re:Anyone want to translate this into dummy speak? (Score:5, Informative)
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.
Re:Anyone want to translate this into dummy speak? (Score:4, Informative)
Based on the advisory, I can't fully agree with either of these statements.
The advisory states:
Any application which uses BIO or FILE based functions to read untrusted DER
format data is vulnerable.
DER is a format for the certificate key. For the most part it's relatively rare to handle untrusted certificate keys. I suppose it's possible if you're doing some form of authenticating the client end as well as the server end via SSL.
Please correct me if I'm wrong, but I don't see much evidence this vulnerability is anything worth worrying about for the vast majority of people.
Advistory at: http://www.openssl.org/news/secadv_20120419.txt [openssl.org]
Re:It only affects 64 bit systems (Score:5, Informative)
I don't think that's accurate. According to the incident report, the problem is passing a signed int to a function expecting an unsigned int. That means passing unsigned values > 2^(n-1)-1 will cause unexpectedly large allocations leading to a heap overflow regardless of whether n is 32, 64, or 8.
According to the incident report: Producing DER data to demonstrate this is relatively easy for both x86 and x64 architectures.
But I could be wrong...