Using u16::max instead of u16::MAX potentially allows very long certificates
Categories
(Core :: Security: PSM, defect, P1)
Tracking
()
People
(Reporter: theemathas, Assigned: keeler)
Details
(Keywords: reporter-external, sec-low, Whiteboard: [psm-assigned][adv-main135+][adv-ESR128.7+])
Attachments
(1 file, 3 external files)
|
172 bytes,
text/plain
|
Details |
Steps to reproduce:
Sorry if this is the incorrect place to file this report. I found this code which is definitely incorrect: https://github.com/mozilla/gecko-dev/blob/48caa4719ed2c75a2937bcfea9e7326e87846984/security/manager/ssl/cert_storage/src/lib.rs#L1037
In rust, u16::max is a function (it takes two numbers and returns the larger one). On the other hand, u16::MAX is a value equal to 2^16-1. The code in the link is u16::max when the intention was u16::MAX. The code then converts the function pointer into an integer, which results in a large integer. Which means that this validation logic could potentially accept very long certificates as valid.
Actual results:
N/A
Expected results:
N/A
Updated•1 year ago
|
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Setting security flag, just in case, we can always declassify.
| Assignee | ||
Comment 2•1 year ago
|
||
Good catch! In practice, I don't think this is an issue, because all of these certificates are coming from Mozilla.
| Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 6•1 year ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D233775
Updated•1 year ago
|
Comment 7•1 year ago
|
||
beta Uplift Approval Request
- User impact if declined: this probably won't affect users, because the data comes from a trustworthy source, but still, it's definitely wrong
- Code covered by automated testing: yes
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: n/a
- Risk associated with taking this patch: low
- Explanation of risk level: this patch changes some casts into statements that can be typechecked by the compiler, so it's definitely safer
- String changes made/needed: none
- Is Android affected?: yes
| Assignee | ||
Comment 8•1 year ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D233775
Updated•1 year ago
|
Comment 9•1 year ago
|
||
esr128 Uplift Approval Request
- User impact if declined: this shouldn't affect users, since the data comes from a trusted source, but it's still wrong
- Code covered by automated testing: yes
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: n/a
- Risk associated with taking this patch: low
- Explanation of risk level: this patch changes some casts into statements that can be typechecked by the compiler, so it's definitely safer
- String changes made/needed: none
- Is Android affected?: yes
Comment 10•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•1 year ago
•
|
||
Backed out changeset 94b283c7793f for causing build bustages: https://hg.mozilla.org/releases/mozilla-esr128/rev/9d507a026111de465ea2198b61e8e610cd64a6ae
Failure log
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 13•1 year ago
|
||
I updated the esr128 patch - should be good to go now.
Comment 14•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 15•1 year ago
|
||
Updated•1 year ago
|
Comment 16•1 year ago
|
||
I was asked to make this public and this was fixed more than 3 months ago. There is also little new information from what is already public in https://github.com/rust-lang/rust-clippy/issues/13973#issuecomment-2833386390.
Description
•