Bug 510219 - openssl leading 0's when handling OID names
openssl leading 0's when handling OID names
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
reported=20090225,public=20090729,imp...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-08 08:04 EDT by Mark J. Cox
Modified: 2009-12-02 09:34 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-02 09:34:31 EST
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-08 08:04:42 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 2b, subattack 1' is where a malicious certificate can contain leading 0's in the OID.  The idea is that the attacker could add in some OID into a certificate that, when handled by the CA, would appear to be some extension and ignored, but when handled by OpenSSL would appear to be the Common Name OID.  So the attacker would present the certificate to a client application using OpenSSL and it might think that the OID is actually a Common Name, and accept the certificate where it otherwise should not.

However this turns out to not be a security issue as although OpenSSL will display the OID for a Common Name, it does not believe it to be a common name.

Steve Henson from OpenSSL explains: "OpenSSL does tolerate leading 0x80 but it does _not_ recognize this as commonName because the NID code checks for a precise match with the encoding.  Attempts to print this out will never show commonName nor will attempts to look up using NID_commonName. So it would need something really weird to misinterpret this such as something which obtains all OIDs in numeric form and does its own lookups bypassing some but not all of OpenSSL's OID library."

So OpenSSL will probably fix this as a bug fix in the future (perhaps rejecting such an invalid OID encoding)
Comment 1 Mark J. Cox 2009-07-08 08:11:32 EDT
Note: NSS is noted as having a similar issue, but again it's not fooled into treating the OID as a Common Name.
Comment 2 Mark J. Cox 2009-07-30 11:41:40 EDT
Dan gave his presentation at Blackhat yesterday, opening bug
Comment 3 Mark J. Cox 2009-12-02 09:34:31 EST
No plan to address this as a security fix for Red Hat Enterprise Linux 3 or 4.  This issue doesn't affect OpenSSL in Red Hat Enterprise Linux 5.

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