Firefox incorrectly parses the version in digital certificates
Categories
(Firefox :: Security, defect, P3)
Tracking
()
People
(Reporter: 2295456556, Unassigned)
Details
Attachments
(6 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0
Steps to reproduce:
1.Mutating a certificate.
2.Running the browser to parse the mutated certificate file.
3.Observing the results.
Actual results:
In file 1, the TLV data representing the version is '1f 02 01 02'.
In file 2, the TLV data representing the version is 'f4 02 01 02'.
However, Firefox parses these two non-standard TLV data as version 3 (file 1) and version 1 (file 2) respectively.
Expected results:
Firefox can parse the version in digital certificates correctly.
Reporter | ||
Comment 1•1 year ago
|
||
Reporter | ||
Comment 2•1 year ago
|
||
Reporter | ||
Comment 3•1 year ago
|
||
1.der and 2.der are actually in PEM format.
1_der.der and 2_der.der are in DER format.
Reporter | ||
Comment 4•1 year ago
|
||
Reporter | ||
Comment 5•1 year ago
|
||
Comment 6•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 7•1 year ago
|
||
When you say Firefox parses these, you're referring to the certificate viewer, right?
Reporter | ||
Comment 8•1 year ago
|
||
What I observe is the result of the certificate viewer. Isn't the certificate viewer displaying the content of the certificate parser?
Comment 9•1 year ago
|
||
Firefox has a number of certificate parsers. The parser used by the certificate viewer is essentially informational only. Firefox doesn't make any security decisions based on its results.
Reporter | ||
Comment 10•1 year ago
|
||
Our idea is that the certificate parser may parse incorrect results. The incorrect parsing results may affect the validation of the certificate validator, resulting in security issues. Papers in related fields have proven that incorrect parsing results can indeed affect the validation results of certificates. So we are trying to find vulnerabilities in the parser. However, the information displayed by the certificate viewer does not seem to be completely equivalent to the information parsed by the certificate parser. So is there any way to programmatically retrieve the certificate parser's parsing results for certificates. For example, certain APIs. I hope to receive your help to better devote myself to this work.
Comment 11•1 year ago
|
||
The certificate parser Firefox uses for TLS is mozpkix: https://searchfox.org/mozilla-central/source/security/nss/lib/mozpkix
See also https://searchfox.org/mozilla-central/source/security/certverifier/, particularly CertVerifier and NSSCertDBTrustDomain.
Comment 12•1 year ago
|
||
The severity field is not set for this bug.
:serg, could you have a look please?
For more information, please visit BugBot documentation.
Comment 13•1 year ago
|
||
Hello! I have tried to reproduce the issue with firefox 122.0a1(2023-12-12) on Ubuntu 22.04, unfortunately I wasn't able to reproduce the issue on my end. Could you please answer the following questions in order to further investigate this isssue.
- Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
- Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
- Do you have any addons installed? If yes could you please list them?
Reporter | ||
Comment 14•1 year ago
|
||
Here is my attempt at redescribing this report:
The problem occurs in Windows 10 22H2 with Firefox version 120.0.1 (64 bits).
The files '1.der' and '1_der.der' represent the same certificate, except '1.der' is actually in PEM format while '1_der.der' is in DER format.
Similarly, '2.der' and '2_der.der' represent the same certificate, with '2.der' in PEM format and '2_der.der' in DER format.
Let's focus on the DER formatted files for now.
(1) In '1_der.der', we mutated the TLV node content representing the version from '02 01 02' to '1f 02 01 02'. However, Firefox still parsed this non-standard data as version 3. Since '02 01 02' represents version 3, I believe it is incorrect for Firefox to interpret '1f 02 01 02' as version 3 as well.
(2) In '2_der.der', we mutated the version TLV content from '02 01 02' to 'f4 02 01 02'. Firefox parsed this non-standard data as version 1, while '02 01 02' actually represents version 3 and '02 01 00' represents version 1. So I believe it is also incorrect for Firefox to parse 'f4 02 01 02' as version 1.
Please refer to the latest two uploaded .png images for the specifics.
Reporter | ||
Comment 15•1 year ago
|
||
Reporter | ||
Comment 16•1 year ago
|
||
Updated•7 months ago
|
Comment 17•7 months ago
|
||
Dana, could you assess the severity of these related bugs for us, please?
I'm not sure if we need to fix and if this is the correct component. Would it also fit into PSM?
Comment 18•7 months ago
|
||
These are all display bugs that have a low (or zero) impact on the average user. Firefox :: Security is an appropriate component, as that's where bugs in the certificate viewer typically are.
Description
•