Bug 510433 - openssl compat mode x509 subject name injection
openssl compat mode x509 subject name injection
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-09 05:12 EDT by Mark J. Cox
Modified: 2009-07-31 10:33 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox 2009-07-09 05:12:36 EDT
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 05:25:21 EDT
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 11:43:24 EDT
removing embargo, Dan gave presentation at Blackhat yesterday.

Note You need to log in before you can comment on or make changes to this bug.