On 1/28/15 6:55 AM, Evgeny Kotkov wrote:
> Here is a couple of findings I would like to share.
> I took the certificates from a regression suite in  and fed them to the new
> X509 parser, svn_x509_parse_cert(). The parser currently fails to parse 20 of
> the test certificates, mostly with an SVN_ERR_ASN1_LENGTH_MISMATCH.
> Please see the attached fails log. I think that the only expected failure is
> the last one, google.pem_cert.p7b, which happens with a deliberately broken
> PEM certificate stored in a file with a .p7b extension. Other failures look
> quite unexpected to me. Failing certificates are a bit special Ś for instance,
> one of them has the EKU set to Code Signing (184.108.40.206.220.127.116.11.3), and the other
> ones are using 768-bit RSA, but I would not say this is a reason for the parser
> to break on them. Other existing parsers, like the one provided within the
> CryptoAPI , do not error out when parsing them.
> I might be missing something, because I did not examine the root cause of this
> behavior. Also, I did not review the branch itself, so, no comments on merging
> it to trunk.
This may be a case of our parser being overly paranoid about the input data
being consistent. The buffer you pass to svn_x509_parse_cert() must end at
exactly the place where the initial SEQUENCE says it should. Put an extra byte
on the end and our parser will error out.
Not sure how you're processing those cert files (and you have to be doing
something since our parser only accepts DER certs and most of those are PEM)
but that's where the problem could be. I'm writing a quick little command line
tool that can read PEM, raw base64 encode certs (i.e. PEM without the
header/footer) and DERs and feed them through our parser. Which should make it
trivial to test arbitrary certificates.
Received on 2015-01-28 20:01:11 CET