Well, with updates to LibreSSL (2.1.7, 2.2.0) getting released today it looks like this has already been addressed. I can't find a decent link at the moment but according to an email I received a bit ago from owner-announce at openbsd.org 1788 is fixed in the above mentioned releases.
Fixes for the following issues are integrated into LibreSSL 2.1.7
and LibreSSL 2.2.0:
- CVE-2015-1788 - Malformed ECParameters causes infinite loop
- CVE-2015-1789 - Exploitable out-of-bounds read in X509_cmp_time
- CVE-2015-1792 - CMS verify infinite loop with unknown hash function
(this code is not enabled by default)
Your comment is probably correct regarding that one issue, but multiple issues were announced today. These include CVE-2015-4000, which is another nasty downgrade issue.
(I'm mostly posting this because I don't want anyone to read your post and think they can ignore this whole notice.)
Are you sure? I'm running Firefox 38.0.5 and Chromium 40.0.2214.91 through normal channels (ie, not nightly builds...) and they are both NOT vulnerable.
38.0.5 is safe. I learned it myself when trying to use internal service.
Secure Connection Failed
An error occurred during a connection to 10.xx.yy.xx. SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)
- The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
- Please contact the website owners to inform them of this problem.
It's hard to tell from the paper, because they don't include either specific build version numbers of browsers / servers nor date of publication, so their results are difficult (e.g., impossible) to reproduce exactly.
I can answer that I found CVE-2015-1789 twice with afl (through different input vectors) and a couple of other issues that were not security-relevant.
I'd assume that the null ptr pkcs#7 issue found by Michal Zalewski was also afl and the ecc issue as well (as documented by its founder). The CMS loop issue sounds also like it could've been found by fuzzing.
It's important to keep in mind what fuzzing can and can't do. It is a great method to find some bugs, but it has its limitations and can only find a certain class of bugs.
Good luck in updating it in OS X (try running `ssh -V` there). Good that OS X will update to a more recent version in El Capitan and also switch to LibreSSL (great step forward).
SSH under OS X uses OSSLShim, which is wrapper around Secure Transport. I'm not exactly sure when they started using it for this, but it has been a while.
If you're seeing OpenSSL in the output, you have probably installed SSH via Homebrew.
Can you explain why LibreSSL is a bad choice for the next OS X version? Maybe OpenSSL & LibreSSL are not fixed on exactly the same day (but around the same time region) but this is not bad IMHO.
The last time a bunch of OpenSSL CVEs dropped, there were 14 of them; two of which were rated sev: High. LibreSSL was affected by 5 out of the 14, none of which were high-severity.
This time around there are seven vulnerabilities and LibreSSL is affected by four of them[1].
"X509_cmp_time does not properly check the length of the ASN1_TIME string and can read a few bytes out of bounds."
OpenSSL in C has had range errors discovered for over a decade now. Short of going to a safe language or full machine proofs of correctness, it's never going to be fixed. "Many eyes" don't help.
(Of course, one wonders how many OpenSSL security holes are deliberate backdoors.)
There's another option: Openssl code is terrible. Even interacting with it is terrible. I had to deal with x509 code lately, and it's probably the worst and least documented code I've seen in a long time.
For the "many eyes" situation to work, you have to have code which "many eyes" can understand. Asn1-related functions in openssl are not in that situation.
Edit: If you've never looked at openssl code, check this out: https://github.com/openssl/openssl/blob/063dccd027033401912d... - yup - that's part of public interface. It's got a mention on the man page, but no idea what encoding it actually outputs. Maybe ascii, maybe something else. Good luck finding out from source.
Edit2: Just a few lines above you can spot: "/* memory leak, buit should not normally matter */"
Yes, the sources are difficult to read at best. The documentation for the public APIs is not much better either.
For example, the suggestion at this page: https://www.openssl.org/docs/crypto/sha.html to use the higher-level EVP_ functions was difficult to actually adhere to, given that the EVP_ functions themselves don't actually explain how to generate a message digest given some input data. I wasted half a day once trying to understand how those functions worked once before giving up and just using the digest functions directly. It's still not clear to me why the EVP functions provide a significant advantage, or even how I would use them to accomplish the use cases outlined in the digest functions.
I suspect that not understanding the OpenSSL APIs is a common problem, and possibly an underlying cause of a lot of crypto implementation errors.
> It's still not clear to me why the EVP functions provide a significant advantage
In case of EVP_... your code is not hardcoding the hash type. You can provide the hash by its name in the config file without any code changes in the app. When using hash contexts directly, you're stuck with what you implement.
That's what I figured when I implemented it. In my application I'm fine hardcoding the hash type because if we have to change hashes away from SHA-2 we have to update all of the equipment in the field anyway, so we might as well update the software at the same time.
E: It also helps that the code with the hardcoded hash type is much easier to understand than the equivalent EVP code.
https://jbp.io/2015/06/11/cve-2015-1788-openssl-binpoly-hang...
It's embarrassing rather than terribly dangerous.
edit: Please note: there are other issues in this advisory. You should read the advisory, first and foremost.