1599331 - NSS UTCTime parser should reject short fields (e.g., should require the seconds digits).

Status: NEW

(NSS :: Libraries, enhancement, P3)

Description

[13132239506]

Attachment: file.tar including required certificates（Including powerca.cert.pem , rootca.cert.pem and id:000123src:000012+000029op:splicerep:2）

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce:

I can reproduce by following these steps:
1.Create folder by “mkdir nssdb”
2.Creating NSS database through "certutil - N - d dbm:nssdb"
3.Add certificates (powerca.cert.pem and rootca.cert.pem) to nssdb database by the command "certutil - A - n powerca.cert.pem - t "c, c, c" - i powerca.cert.pem - d nssdb" and the command "certutil - A - n rootca.cert.pem - t "c, c, c" - i rootca.cert.pem - d nssdb"
4. verify the certificate id:000123src:000012+000029op:splicerep:2 with a notbefore field of length 11 （ "0103010100Z"）by "vfychain -a -d nssdb id:000123src:000012+000029op:splicerep:2"

Actual results:

Chain is good!

Expected results:

Chain is bad!
The RFC standards for X.509 certificates restrict the notbefore field to only two forms, namely the ASN.1 representations of UTCTime (YYMMDDHHMMSSZ) and GeneralizedTime (YYYYMMDDHHMMSSZ) which are 13 and 15 characters wide respectively. so, it shoud reject the certificate with a notbefore field of length 11 （ "0103010100Z"）.

Comment 1

[J.C. Jones [:jcj] (he/him)]

I'm pretty sure by default this is using the certhigh verifier, which has known incompatibilities and is not nearly as strict as mozilla::pkix. (See https://wiki.mozilla.org/SecurityEngineering/Certificate_Verification)

That said, this points to our implementation of something in the decoder being more lax than is warranted.

Comment 2

[J.C. Jones [:jcj] (he/him)]

Can you dig into this behavior a bit, Franziskus?

Comment 3

[Franziskus Kiefer [:franziskus]]

I guess there are two sides to this.

1. It appears the UTCTime of length 11 is generally excepted by ASN.1 parsers (simply skipping the seconds), e.g. openssl or pyca.
2. mozpkix, which is used in Firefox, rejects UTCTime of length 11.

This tells me that it might have been a common issue such that many libraries accepted it. But it doesn't seem to be an issue anymore as Firefox works just fine with being more restrictive.
So the question is if this should get fixed in the NSS parser but I don't see a security issue here.

Comment 4

[13132239506]

(In reply to J.C. Jones [:jcj] (he/him) from comment #1)

I'm pretty sure by default this is using the certhigh verifier, which has known incompatibilities and is not nearly as strict as mozilla::pkix. (See https://wiki.mozilla.org/SecurityEngineering/Certificate_Verification)

That said, this points to our implementation of something in the decoder being more lax than is warranted.

First of all, thank you for replying to me. Sorry, i'm not particularly familiar with nss. I simply use “vfychain” to verify the certificate for testing. What should I do if I use mozilla :: pkix to verify the certificate? Can you tell me? Thank you very much.

Comment 5

[J.C. Jones [:jcj] (he/him)]

(In reply to 13132239506 from comment #4)

First of all, thank you for replying to me. Sorry, i'm not particularly familiar with nss. I simply use “vfychain” to verify the certificate for testing. What should I do if I use mozilla :: pkix to verify the certificate? Can you tell me? Thank you very much.

It really depends on your use case, and without more information I can't really provide much guidance. vfychain implements the PKIX algorithm but doesn't provide all the guarantees that a web browser would need on the Web PKI. If you're using a simpler PKI structure then I imagine what you're doing would be fine. Since this issue is about a private PKI, I think you're doing fine with just vfychain.

As Franziskus said, being overly permissive with this date isn't a security issue. It's definitely a compliance issue, but that also goes both ways. Mozilla::PKIX is much more strict on these things as CAs on the WebPKI are required to conform strictly to the Baseline Requirements. In your scenario, your CA issued a certificate that is compliant with the NSS command line utilities but not with Firefox. That seems like it's probably OK and itself not a security issue either, just a compatibility one.

Since OpenSSL and PyCA accept these 11-char-long UTCTime lengths, it might break people when we change the NSS parser. But it seems worthwhile to do, if just for these cases. I agree with marking this P3, but I'm going to open this up to no longer be a security-sensitive bug.

Comment 6

[13132239506]

(In reply to J.C. Jones [:jcj] (he/him) from comment #5)

(In reply to 13132239506 from comment #4)

First of all, thank you for replying to me. Sorry, i'm not particularly familiar with nss. I simply use “vfychain” to verify the certificate for testing. What should I do if I use mozilla :: pkix to verify the certificate? Can you tell me? Thank you very much.

It really depends on your use case, and without more information I can't really provide much guidance. vfychain implements the PKIX algorithm but doesn't provide all the guarantees that a web browser would need on the Web PKI. If you're using a simpler PKI structure then I imagine what you're doing would be fine. Since this issue is about a private PKI, I think you're doing fine with just vfychain.

As Franziskus said, being overly permissive with this date isn't a security issue. It's definitely a compliance issue, but that also goes both ways. Mozilla::PKIX is much more strict on these things as CAs on the WebPKI are required to conform strictly to the Baseline Requirements. In your scenario, your CA issued a certificate that is compliant with the NSS command line utilities but not with Firefox. That seems like it's probably OK and itself not a security issue either, just a compatibility one.

Since OpenSSL and PyCA accept these 11-char-long UTCTime lengths, it might break people when we change the NSS parser. But it seems worthwhile to do, if just for these cases. I agree with marking this P3, but I'm going to open this up to no longer be a security-sensitive bug.

I see, thank you very much

Comment 7

[13132239506]

ok