OpenSSL Security Advisory

[pilif]

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails

I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be broken.

Additionally, your callers will start to depend on your behaviour and suddenly you have what amounts to two separate implementations in your code.

I learned that while blowing up (though don't call exit if you're a library. Please.) is initially annoying for callers, in the end, it will be better for you and your callers because code will be testable, correct and more secure (because there's less of it)

[toast0]

Alternate chains aren't a broken input issue; it's an issue where not all clients have the same CAs; so if you need to chain to an old 1024-bit root to take care of really old clients, newer clients without 1024-bit roots should be able to validate still. Older versions of openssl need to keep the 1024-bit root around, because the only validate the full chain provided by the server.

[kaeso]

This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...

[makomk]

Unfortunately, I suspect this feature may be necessary in practice in order to actually expire old, insecure CA certificates that are still in widespread use.

[the8472]

This may be true when accepting input over which the user has control so the library can tell him "do it better".

I would say it's also true for security-related protocols, such as in this case.

But for general network protocols some leniency in processing is necessary, or even beneficial for forwards-compatibility.

[andrewstuart2]

Not only that, but with less and simpler code, there's less cognitive disincentive for people to take a look at it, see what it's doing, and verify that it does what it says it does.

[rjst]

So true.

[judemelancon]

I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug.

Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files suggests the function length matches actual practice elsewhere, too.

[rgj]

And the coding style doesn't exactly avoid errors as well.

"Do not unnecessarily use braces around a single statement:

    if (condition)
        action();

and

    if (condition)
        do_this();
    else
        do_that();

"

Didn't people learn from the goto fail bug ? http://embeddedgurus.com/barr-code/2014/03/apples-gotofail-s...

[sliverstorm]

Reading your comment I initially assumed {i, j} were iterators, in which case they would be fine by me. Nope.

[ajross]

You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary!

I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard idioms.

[jgrahamc]

Interesting part is that the bug was introduced in the latest versions and has been fixed by the person who inserted it :-)

Bug added: https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae...

Bug removed: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365...

Although that's just the committer: https://twitter.com/agl__/status/619129579580469248

[acqq]

Looking at the changes that introduced the bug, it's obvious that the nature of the problems being solved is too complex for the changes to be only "visually" reviewed. There must be enough external tests to "uncover" the potential issues. And the tests of course can have the bugs too, not covering what needed to be covered. That's why for so sensitive code the testers should be the best programmers with additional preference to search for the combinations that don't work as intended.

[amirmc]

Yep, that the bug was recently introduced was implied from the notice they put out.

For interest, the line that was fixed from the first commit is:

https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae...

[Kapow]

    /* Remember how many untrusted certs we have */
    j = num;

Flawless.

[acqq]

We probably don't need to worry this time:

https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/

"The vulnerability appears to exist only in OpenSSL releases that happened in June 2015 and later. That leaves a lot of Linux distributions relatively safe, since they haven't gotten an OpenSSL update in a while.

Red Hat, CentOS and Ubuntu appear to be entirely unaffected by this vulnerability, since they had no OpenSSL updates since June 2015."

[drzaiusapelord]

Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed?

No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment.

LibreSSL looks promising. Hopefully competition will mean better outcomes for such critical libraries.

[mykhal]

from test/verify_extra_test.c:

    Test for CVE-2015-1793 (Alternate Chains Certificate Forgery)
   
    Chain is as follows:
   
    rootCA (self-signed)
      |
    interCA
      |
    subinterCA       subinterCA (self-signed)
      |                   |
    leaf ------------------
      |
    bad
   
    rootCA, interCA, subinterCA, subinterCA (ss) all have CA=TRUE
    leaf and bad have CA=FALSE
   
    subinterCA and subinterCA (ss) have the same subject name and keys
   
    interCA (but not rootCA) and subinterCA (ss) are in the trusted store
    (roots.pem)
    leaf and subinterCA are in the untrusted list (untrusted.pem)
    bad is the certificate being verified (bad.pem)
   
    Versions vulnerable to CVE-2015-1793 will fail to detect that leaf has
    CA=FALSE, and will therefore incorrectly verify bad

[mvanotti]

So, bad certificate HAS to be signed by leaf certificate, and leaf certificate HAS to be trusted. (And you need two CAs with the same keys)

openssl would accept certs that have been issued by a non-ca cert (which is trusted).

So if you have control over the leaf cert, you can just use it for contacting openssl.

If you don't have control over the leaf cert, you can't issue a bad cert.

Am I missing something?

[d_theorist]

So, updating server side OpenSSL will not close this vulnerability (for servers offering https-protected websites)? Is that correct?

If I understand the advisory correctly then this means that somebody could set up a webserver with a specially-crafted certificate and pretend to be somebody else, assuming that the client is running a vulnerable version of OpenSSL.

Is that right? I wish they would write these advisories in a slightly more helpful fashion.

[tedunangst]

Yes, this is a client side bug.

[jarofgreen]

In case it's slow:

OpenSSL Security Advisory [9 Jul 2015]

=======================================

Alternative chains certificate forgery (CVE-2015-1793)

======================================================

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate.

This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.

Note

====

As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade.

References

==========

URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt

Note: the online version of the advisory may be updated with additional details over time.

For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html

[coolowencool]

"No Red Hat products are affected by this flaw (CVE-2015-1793), so no actions need to be performed to fix or mitigate this issue in any way." https://access.redhat.com/solutions/1523323

[batou]

Well there goes my long laborious afternoon of sysadmin work that I wasn't looking forward to! :-)

[aninteger]

Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.

[jerf]

Probably because once you wrap your code around one SSL stack it's hard to migrate it to another. So you stick to the one you use first. OpenSSL, for instance, isn't just an SSL library... since C has no standardized "stream" functionality, it's a whole big generic streaming library with pluggable modules for various streams and the ability to write your own... once you're stuck to that you can get stuck pretty hard if you don't properly wrap it with abstraction, which C is not, ahhh... let's say it's not really the best at that sort of thing anymore, which is of course partially because every language since C has known that it needs to be better than C at this to even be considered by anybody.

[TheDong]

You missed the two oldest and most mature alternatives: libnss (firefox) and gnutls.

[binarycrusader]

Because, quite frankly, many FOSS components are not that actively maintained, and all of the alternatives either raise licensing considerations, were not intended for use by general projects, or are not significantly mature yet.

Many projects have also invested heavily into optimizing the performance of OpenSSL itself or the use of its interfaces.

You can't sprinkle "magic SSL dust" over these components and just start using an alternative. In some cases, significant, non-trivial changes would be required to change which library is used.

The reality is, as fast as OpenSSL development is moving now, it remains the better option for a lot of projects because of the significant investments already being made and concerns I mentioned earlier.

[dozzie]

Because despite bug history of OpenSSL, nothing proved to be more reliable to this moment.

[tanderson92]

Some linux distributions allow you to choose your implementation of SSL upfront, be it libressl or openssl.

See: Exherbo Linux (http://www.exherbo.org/docs/eapi/providers-and-virtuals.html). This isn't one of the big distros, but you do have a choice.

[Mojah]

This appears to be the actual code fix: https://github.com/openssl/openssl/commit/aae41f8c54257d9fa6...

Some more details & patching guide here: https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/

[edwintorok]

This is relevant too: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365...

[0x0]

Debian stable/oldstable is not affected. Only in unstable: https://security-tracker.debian.org/tracker/CVE-2015-1793

[therealmarv]

Well on Ubuntu I see nothing yet... http://www.ubuntu.com/usn/trusty/ I do not know if this is good or bad :(

[ca98am79]

AWS response: http://aws.amazon.com/security/security-bulletins/openssl-se...

[clebio]

Welp, you saved me some work today!

I was considering using the `ec2.py` script from Vagrant's dynamic inventory docs and then running SSH command execution over all our instances to upgrade the packages for both Ubuntu and AWS AMIs (yum), just to be safe. Guess I don't need to after all!

[mykhal]

Changes between 1.0.2c and 1.0.2d [9 Jul 2015]

  *) Alternate chains certificate forgery

     During certificate verfification, OpenSSL will attempt to find an
     alternative certificate chain if the first attempt to build such a chain
     fails. An error in the implementation of this logic can mean that an
     attacker could cause certain checks on untrusted certificates to be
     bypassed, such as the CA flag, enabling them to use a valid leaf
     certificate to act as a CA and "issue" an invalid certificate.

     This issue was reported to OpenSSL by Adam Langley/David Benjamin
     (Google/BoringSSL).
     [Matt Caswell]

[runesoerensen]

It's worth noting that only releases since June 2015 are affected

[marcosdumay]

That means, only releases that have no other known high severity bugs...

[benmmurphy]

An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method (https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-...) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is signed by a certificate in the trust store. it then explicitly returns it as the trusted_ca which effectively means the certificate has the CA bit set on it.

in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: (https://twitter.com/benmmurphy/status/613733887211139072)

'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.'

and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this:

    RANDOM CERT SIGNED BY ISSUER NOT IN TRUST STORE
    |
    V
    VALID_CERT_SIGNED_BY_CERT_IN_TRUST_STORE (effectively treated as CA bit set)
    |
    V
    EVIL CERTIFICATE SIGNED BY PREVIOUS CERT

[yuhong]

AFAIK the Baseline Requirements don't allow it but old certs that are not expired may still exist. It was one of the reasons why the e-Guven root was removed from Mozilla.

[kfreds]

The latest version (2.3.7) of the official OpenVPN client is vulnerable, as is Tunnelblick for OSX. No fix has been published yet. The OpenVPN clients for Android and iOS are not affected.

See https://mullvad.net/en/v2/news for more details.

[namtrac]

OpenVPN already updated: http://article.gmane.org/gmane.network.openvpn.devel/9900

[syzzer]

Note that this is specifically OpenVPN on Windows, since the Windows installers ship with their own openssl dll (and as already said by the other commenter, a new installer was made available around the time of your post). All other platforms simply use the system library.

[0x0]

This sounds really familiar to the old IE bug that didn't check the CA flag - http://www.thoughtcrime.org/ie-ssl-chain.txt

[api]

A lot of these SSL vulnerabilities show that complexity is an inherently bad thing for security. In general, bugs in a system are exponentially not linearly proportional to system complexity. With security that means that the addition of a feature, option, or extension to the security layer of a system exponentially decreases its trustworthiness.

[mugsie]

Seems to be OK for anyone using non beta versions of Ubuntu as well:

http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...

[eatonphil]

I've got a few sites using OpenSSL certs; do I need to do anything?

[marcosdumay]

Unless you are using client side certificates, this one is not your problem.

But everybody must upgrade their browsers ASAP.

[nkozyra]

SSL does not necessarily mean OpenSSL is involved, but it could. Follow the advisories.