

OpenSSL Security Advisory - eyeareque
https://www.openssl.org/news/secadv_20150611.txt

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

[https://jbp.io/2015/06/11/cve-2015-1788-openssl-binpoly-
hang...](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.

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

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

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

~~~
kardos
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.

~~~
ikeboy
40.0.2214.91 was released months ago
[http://googlechromereleases.blogspot.com/2015/01/stable-
upda...](http://googlechromereleases.blogspot.com/2015/01/stable-update.html).
(Irony of no https).

[https://bugzilla.mozilla.org/show_bug.cgi?id=1166031](https://bugzilla.mozilla.org/show_bug.cgi?id=1166031)
and
[https://bugzilla.mozilla.org/show_bug.cgi?id=1138554](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/](https://weakdh.org/) and
[https://www.ssllabs.com:10445/](https://www.ssllabs.com:10445/)

~~~
takeda
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.

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

~~~
what_the_diffie
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](https://weakdh.org/imperfect-forward-secrecy.pdf)

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

~~~
hannob
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.

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

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

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

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

~~~
nifoc
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.

~~~
sslalready
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...](https://developer.apple.com/library/ios/documentation/Security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html)

------
Animats
_" 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.)

~~~
viraptor
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...](https://github.com/openssl/openssl/blob/063dccd027033401912d8c5e3f0f25b1f13de64b/crypto/objects/obj_dat.c#L465)
\- 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 */"

~~~
jschwartzi
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](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.

~~~
viraptor
> 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.

~~~
jschwartzi
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.

