Bug 510433

Summary: openssl compat mode x509 subject name injection
Product: [Other] Security Response Reporter: Mark J. Cox <mjc>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: unspecifiedCC: security-response-team, vdanen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-19 09:03:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mark J. Cox 2009-07-09 09:12:36 UTC
In his upcoming Blackhat paper and presentation Dan Kaminsky
highlights some more issues he has found relating to SSL hash
collisions and related vulnerabilities.

His second issue is all about inconsistencies in the interpretation of subject
x509 names in certificates.  Specifically "issue 2d' is how the OpenSSL command line utility will output unescaped subject X509 lines to the standard output.  

So if some utility runs the openssl application from the command line and parses the text output, and if an attacker can craft a malicious certificate 
in such a way they fool a CA into signing it, they could present it to the utility and possibly fool that utility into thinking fields were different to they actually are, perhaps allowing the certificate to be accepted as legitimate.

So this attack assumes that some utility will parse the output of OpenSSL command line using the default 'compat' mode.  Applications should never do this anyway.

So upstream OpenSSL are unlikely to address this issue directly, although in the future the default output mode could be changed to something other than 'compat'.  The likely response will be documentation reminding people that parsing the output of running such an openssl command is not the right way to use OpenSSL.

Comment 1 Mark J. Cox 2009-07-09 09:25:21 UTC
Section 2d also mentions a non-exploitable read AV.  This was fixed as CVE-2009-0590 in upstream OpenSSL 0.9.8k

Comment 2 Mark J. Cox 2009-07-30 15:43:24 UTC
removing embargo, Dan gave presentation at Blackhat yesterday.