Issue metadata
Sign in to add a comment
|
Security: A remote attacker can break TLS due to missing validations on X509 v1 issued certificates in Chrome
Reported by
abhinav....@gmail.com,
May 29 2017
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS If a trusted Certificate Authority issues a X509v1 certificate, then Chrome on MacOS doesn't do any validations on the issued certificate which can be used as an Intermediate Certificate Authority to generate leaf certificates for arbitrary domains. This allows an attacker to get a X509v1 leaf certificate for its own domain from a Trusted Root Authority such as DigiCert etc. and then use it to sign certificates for any other domain. In X509 v3 standard, this issue doesn't arise as it is controlled using X509 v3 extension: Basic Constraint CA=true. Chrome will trust a leaf certificate only if the CA component is set to true for all issuing certificates in the chain. However since x509 v1 standard doesn't specify any such constraint, Chrome happily trusts the rogue certificate allowing a remote attacker to defeat TLS. A possible remediation is to stop the processing on encountering the first x509v1 certificate in the certificate chain or give an appropriate warning to the user. Tested with firefox as well which gives appropriate warning to the user. The vulnerability can be exploited by remote attackers to compromise SSL and leak sensitive user data including passwords and financial information VERSION Chrome Version: 58.0.3029.110 (64-bit) Operating System: MacOS 10.12.5 (16F73) REPRODUCTION CASE For demo purposes, I created a root CA conforming to x509v3 standard that has basic constraints CA=true set. This CA is marked as trusted for the user account in the user keychain. This CA issues a x509v1 certificate to an Example domain. The attacker leverages the vulnerability to issue leaf certificates for arbitrary domains [eg. twitter.com] and perform MITM attack. FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: [tab, browser, etc.] Crash State: [see link above: stack trace, registers, exception record] Client ID (if relevant): [see link above]
,
May 30 2017
> If a trusted Certificate Authority issues a X509v1 certificate Did you attempt to induce any CA to do so?
,
May 30 2017
I'm marking this as WontFix. While in general, we operate on the principle of "defense in depth", an X.509v1 certificate is implicitly a CA certificate. The distinction between the two is only readily apparent in X.509v3, which introduced the basicConstraints extension to distinguish them (and defaulted all certificates lacking a basicConstraints to false). No publicly trusted CA is permitted to issue an X.509v1 certificate. If such a certificate has been issued, then the CA has failed to abide by Chrome's Root Certificate Policy ( https://www.chromium.org/Home/chromium-security/root-ca-policy ) and the CA/Browser Forum's Baseline Requirements ( https://cabforum.org/baseline-requirements-documents/ ) While it's possible to make the argument that Chrome should not support X.509v1 certificates - particularly if the belief is that they are not used on the Public Internet - they are fully defined within the context of RFC 5280 and, for better or worse, widely deployed within private intranet deployments (e.g. the default generated by many OpenSSL tools) Because we have addressed this concern via policy, rather than code, I'm marking this as WontFix/WorkingAsIntended. At this time, we have not announced any public plans to deprecate X.509v1 certificates (in public or private networks), and relative to other priorities, do not believe this represents a vulnerability per-se.
,
May 31 2017
A threat model that involves a CA misissuing a certificate (as v1) is no different than a threat model that involves a CA misissuing a certificate (e.g. with basicConstraints=true). While you reference 2002, since 2012, all CAs have been expected to abide by the Baseline Requirements, and Chrome itself has its own policies regarding root CAs ( https://www.chromium.org/Home/chromium-security/root-ca-policy ). A CA found to be violating those policies, especially in a way that presents active risk to user, is a CA at risk for complete distrust and removal. Security Team: My advice is we should move this bug out of the security queue and open it up. It's not a security bug.
,
May 31 2017
Ok. Is it possible to keep it in the queue with "Wont fixed" status, till I get a response from few other vendors and get their feedback?
,
Sep 6 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kenrb@chromium.org
, May 29 2017Components: Internals>Network>Certificate