OpenSSL Security Advisory | Hacker News Reader

OpenSSL Security Advisory

openssl.org

129 pointseyeareque38 comments

Here's a writeup of CVE-2015-1788:

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.

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

I think Logjam is the only operationally significant bug in this announcement.

You're right, of course. But CVE-2015-4000 was announced and extensively discussed a number of weeks ago: https://weakdh.org/

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)

Edit - The updates included are mentioned here: https://github.com/libressl-portable/portable/blob/master/Ch...

In the meantime, latest stable releases of Chrome and Firefox are still vulnerable to Logjam. Is it that hard to fix?

Use Chrome Canary

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.

40.0.2214.91 was released months ago http://googlechromereleases.blogspot.com/2015/01/stable-upda.... (Irony of no https).

https://bugzilla.mozilla.org/show_bug.cgi?id=1166031 and https://bugzilla.mozilla.org/show_bug.cgi?id=1138554 say explicitly wontfix for 38.0.5

Maybe you manually fixed it some time ago and don't remember?

Check both https://weakdh.org/ and https://www.ssllabs.com:10445/

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.

I wish they gave option to bypass it.

I'm running 38.0.5, the weakdh page says I'm vulnerable

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.

0: https://weakdh.org/imperfect-forward-secrecy.pdf

Interesting, weakdh says I'm safe...

Both on Mac and OpenSuSE.

Ah, it appears that the patches made their way into my distro's packages. I tested both with weakdh.org before posting previous comment.

These major browsers (latest stable on OS X) are currently vulnerable:

- Chrome 43.0.2357.124

- Firefox 38.0.5

- Safari 8.0.6 (10600.6.3)

Not vulnerable

- Opera 30.0.1835.59

Reference: https://www.ssllabs.com/ssltest/viewMyClient.html

I wonder how many of these are found by hand versus with automated tools like Asan and AFL. Seems like some of these would be really hard to spot...

Logjam was found with model-checking software, right?

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.

Yep, the two PKCS bugs were from afl-fuzz.

Layman's explanation? I should apt-get update && apt-get upgrade?

This is OpenSSL's response to the "Logjam" attack (https://weakdh.org/)

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.

These are the versions on 10.10.3:

OpenSSL 0.9.8zd 8 Jan 2015

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

ah ok thanks. Actually I do not see OpenSSL there. I've looked too fast and thought OpenSSL is still used in OS X.

Usage of openssl has been deprecated since OS X 10.7 in favor of Secure Transport and Common Crypto. Furthermore, OpenSSL is not even supported on iOS. See: https://developer.apple.com/library/ios/documentation/Securi...

> Good that OS X will update to a more recent version in El Capitan and also switch to LibreSSL (great step forward).

Not sure if you're being sarcastic?

"LibreSSL has the affected code and is thought to be vulnerable (untested)." - https://jbp.io/2015/06/11/cve-2015-1788-openssl-binpoly-hang...

They released updates today that fix cve-2015-1788.

https://github.com/libressl-portable/portable/blob/master/Ch...

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.

Simply saying with regards to this issue it didn't provide advance protection (that was my impression after reading the comment anyhow)

You claimed that LibreSSL is a great step forward, but there's no reason to think that it's a "great step".

> there's no reason

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

So there's at least 12 reasons.

    [0] https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2
    [1] https://marc.info/?l=openbsd-announce&m=143406498020131&w=2

There were 7 CVEs of which 4 were applicable to LibreSSL, including the one in that link.

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

Reply on news.ycombinator.com