Created attachment 8368646 [details] [diff] [review] suggested patch User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131210132650 Steps to reproduce: CERT_GetCertificateRequestExtensions is hardcoded to expect the PKCS #9 Extension Request attribute as the first attribute in the set of CSR attributes. If the set of attributes is non-empty and the first attribute is not an extensions request the function will misbehave. This problem was first observed by users of python-nss when a CSR was decoded that had a FriendlyName attribute as the first attribute. python-nss reported there were no extensions in the CSR because python-nss had copied the logic found in certutil.c prior to calling CERT_GetCertificateRequestExtensions. It was relatively easy to fix python-nss by eliminating the call to CERT_GetCertificateRequestExtensions and implementing it's own version of the function. Although now python-nss is working correctly the bug remains in NSS and I have a suggested fix. I believe CERT_GetCertificateRequestExtensions needs to be fixed by having it iterate over the set of attributes looking for the extensions attribute. There needs to be a way of indicating there were no extensions in the CSR and there were no errors, i.e. the function succeeded but nothing was found. My suggestion is the exts output parameter be set to NULL and SECSuccess be returned in this case. Although setting the output parameter to NULL would be a change in behavior I don't think it would create any problems because currently if the caller did not set the output parameter to NULL and SECSuccess was returned the caller would dereference a bad pointer. The funky logic in certutil.c can then be removed. I'm attaching a suggested patch for NSS, however I have not actually tested it (sorry). I'm also attaching a trivial Python program that includes a CSR whose extensions are not located at index 0 in the attribute set. Also attached is the output of that program. (Caveat, the version of python-nss with the fix exists only on the tip of the HG branch, I have not yet pushed a public release with the fix yet).
You need to log in before you can comment on or make changes to this bug.