7

The security advisory for the issue can be found here: https://www.openssl.org/news/secadv_20150709.txt

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

4

From the description, one may infer that the attack works the following way (warning: I wrote "infer" and I mean it -- I have not tried it):

  • The attacker is in position to intercept all network traffic from the victim (e.g. the attacker operates the WiFi access point to which the victim unwisely connected).

  • The attacker owns (legitimately !) some domain, let's call it "evilattacker.com", and has bought a completely valid certificate with that name in it; namely, the attacker owns a certificate A, that contains the name www.evilattacker.com, and is signed by some trusted root V. The attacker pushes a copy of that certificate (the public key) on a publicly accessible Web site, say his own site; the corresponding URL may be (for instance) http://www.evilattacker.com/cert.crt (it could also be on any kind of public hosting, it does not matter).

  • The victim wants to connect to its bank site. His browser tries to open a SSL session with www.bank.com.

  • The attacker intercepts that connection and pretends to be the bank. To that effect, the attacker sends a certificate chain C,X (in that order) where:

    • C is a synthetic certificate that contains the name www.bank.com, and is signed with the attacker's own private key, and contains an Authority Information Access extension with a URL equal to http://www.evilattacker.com/cert.crt (that is, pointing to where the attacker has published his own certificate C).
    • X is random junk.
  • The client (victim's browser) will fail to validate the C,X chain, because X is random junk. If the browser uses an old OpenSSL, then things stop there and a connection error is reported. However, if the browser uses a new, affected version of OpenSSL, then it will try to rebuild an alternate chain, following the URL found in C. In particular, the browser will download A (the attacker's certificate) and then V (the external, trusted certificate authority), and will end up with the C,A,V chain.

  • If there was no bug, then the client would reject that new C,A,V chain because even though all cryptographic signatures match, the middle certificate A lacks the Basic Constraints extension with the cA flag set to TRUE: the attacker's certificate is not a CA certificate, so it cannot appear in the middle of a valid chain. However, due to the bug, in that specific situation, affected versions of OpenSSL fail to check the cA flag in the Basic Constraints extension, and accept that C,A,V chain as valid. The browser is persuaded that it talks to the genuine bank server, and proceeds without any warning. The attacker can now run a Man-in-the-Middle attack and plunder the victim's bank account.

Ironically, failure to check the Basic Constraints extension for middle certificates was also a bug in Windows / Internet Explorer circa 2003, and Microsoft was duly and heavily mocked for that; the OpenSSL developers thus just lost all rights to such mocking.

The bug impacts every application that uses an affected version of OpenSSL (not a lot of them, since the buggy code was added only recently), and is in position to process a certificate chain sent by a potentially hostile peer. This means SSL clients (when validating a server's certificate); this also means SSL servers themselves, when (and only when) these servers request certificates from clients (certificate-based client authentication is pretty rare in everyday's Web).

  • OpenSSL has a new test case with some information for this bug: test/verify_extra_test.c. I don't get it. I haven't checked the trust store but it seems weird that there would be a non self signed CA ("InterCA" in their example) in their trust store when it's signing CA is not also inside the trust store. – StackzOfZtuff Jul 9 '15 at 21:53
  • Nicer illustration here: twitter.com/maximilianhils/status/619153452086767616 – StackzOfZtuff Jul 9 '15 at 21:57
  • OpenSSL dev Matt Caswell tried to explain this on OpenSSL-users yesterday. It appears that (1) no AIA downloading is involved, (2) the attacker does not need any MitM capability, just a regular HTTPS server (3) the attacker needs detailed knowledge what is in the victims trusted store and untrusted store in order to send a an untrusted chain that OpenSSL will then rebuild incorrectly. – StackzOfZtuff Jul 11 '15 at 4:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.