First, some background: PKILayerCake is a reference to Dan Kaminsky's examination of some of the flaws with the PKI as it exists today. It can be found at http://www.ioactive.com/pdfs/PKILayerCake.pdf . One of the things that it calls out is related to OpenSSL's default way of printing Distinguished Names from certificates, for example in the x509 -noout -text output.
Quoting from the document: =====begin quote===== OpenSSL’s default “compat” mode for dumping X.509 Subject Names is vulnerable to injection attacks. Independent of special API’s, OpenSSL has three obvious points at which a CA can acquire the X.509 Subject Name for validation: Before signing, by dumping the text of the PKCS#10 Certificate Request, during signing, by analyzing the output of the signing command line, and after signing, by dumping the text of the generated certificate. All three are vulnerable to the First/All Inclusive/Last attack described earlier. During signing, the output becomes “subject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/CN=www.bank.com”, spuriously implying a CN of www.badguy.com is present in the generated certificate. In fact, CN is listed as such because the value on O is “Badguy Inc/CN=www.badguy.com”. Similar text/ASN.1 confusion happens before and after signing – the dumped line is actually escaped out to “O=Badguy Inc, CN=www.badguy.com, OU=Hacking Division, CN=www.bank.com”. It is possible to defend against injection attacks during request or certificate dumping by using any of the (non-default) escaping nameopts, such as RFC2233, oneline, or multiline. Note that it might be worth updating to a new version of OpenSSL, since existing versions have an annoying but ultimately non-exploitable read AV when filtering malicious multibyte strings. =====end quote===== This is because the standard '/' character, as suggested by OSF, is a legitimate possible character within the Subject strings themselves. This problem could also affect more than just CAs. -nameopt oneline provides for all of the DN components to be printed in RFC1779-compliant single-line display. -nameopt multiline provides for all of the DN components to be printed in RFC1779-compliant multiple-line display. What plans, if any, exist to call attention to the default and its potential for spoof/injection attacks? Is there any plan to change the default, or is this expected to be the default in v1.0 as well? (If this should be submitted via rt, I'll happily do so -- discussion might be warranted among interested parties, though.) -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
