[VU#421644] Possible OOM DOS attack via Http2 CONTINUATION frames
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
People
(Reporter: jesup, Assigned: kershaw)
References
(Blocks 1 open bug)
Details
(Keywords: csectype-dos, sec-low, Whiteboard: [embargo while bug 1881164 is][necko-triaged][necko-priority-queue][adv-main125+][adv-esr115.10+])
Attachments
(1 file, 6 external files)
|
248 bytes,
text/plain
|
Details |
There's no limit on the number of Continuation Header frames we'll append to a header, even past the maximum size. This could be leveraged by an evil server to OOM a client. There may be a few variations; see the linked bug.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
I suggest that we could utilize the existing preference (network.http.max_response_header_size, set at 384K) as the maximum limit for the size of received headers in HTTP/2. When reviewing the telemetry probe data, it appears that the value of mAggregatedHeaderSize is smaller than this limit, indicating that the 384K limit should be fine.
| Assignee | ||
Comment 2•2 years ago
|
||
| Assignee | ||
Comment 3•2 years ago
|
||
Depends on D205233
Comment 5•2 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8569d595f6ef
https://hg.mozilla.org/mozilla-central/rev/b46491dc7c5a
Comment 6•2 years ago
|
||
Does this need backport? It grafts cleanly to all branches.
| Assignee | ||
Comment 7•2 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)
Does this need backport? It grafts cleanly to all branches.
Thanks for asking.
I think it's fine to let this ride the train, since this is a sec-low issue.
Comment 8•2 years ago
|
||
The patch landed in nightly and beta is affected.
:kershaw, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox125towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 9•2 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #7)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)
Does this need backport? It grafts cleanly to all branches.
Thanks for asking.
I think it's fine to let this ride the train, since this is asec-lowissue.
It may be a "safe crash" kind of annoyance, but it's also a potentially high-profile cross-industry that is already getting attention. CERT is bugging everyone for status on whether their company is affected. Not just software companies who write networking code, but generally whether their companies are running any of the known affected software from other vendors. It's going to be on government checklists where companies selling services to the gov't have to attest their software is not vulnerable, and several vendors are selling things based on stable Linux distros with ESR Firefox.
We're treating this as "sec-low" because users can recover and then stay away from the asshole server that's crashing them. This is being treated as "sec-high" or close to it by most companies who need to keep their servers running or they are losing buckets of money and customer good will.
We need to ship this on ESR-115. We might as well ship it in Fx125 so we don't undercut any good messaging we got out of how quickly we were able to respond to the Pwn2Own exploit.
Comment 10•2 years ago
|
||
We definitely should not have checked tests in during the embargo period. Catching some heat for that
Comment 11•2 years ago
|
||
assigning CVE-2024-3302 to our implementation's instance of this flaw.
Comment 12•2 years ago
|
||
Valentin, can you please nominate this for uplift since Kershaw is on PTO?
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D205233
Updated•2 years ago
|
Comment 15•2 years ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D205234
Updated•2 years ago
|
Comment 16•2 years ago
|
||
esr115 Uplift Approval Request
- User impact if declined: Potential DOS by server
- Code covered by automated testing: yes
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: -
- Risk associated with taking this patch: low
- Explanation of risk level: The patch is well tested.
- String changes made/needed: none
- Is Android affected?: yes
Updated•2 years ago
|
Comment 18•2 years ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D205233
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D205234
Updated•2 years ago
|
Comment 20•2 years ago
|
||
beta Uplift Approval Request
- User impact if declined: Potential DOS by server
- Code covered by automated testing: yes
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: -
- Risk associated with taking this patch: low
- Explanation of risk level: The patch is well tested.
- String changes made/needed: none
- Is Android affected?: yes
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 21•2 years ago
|
||
| uplift | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 22•2 years ago
|
||
| uplift | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 23•2 years ago
|
||
Updated•2 years ago
|
Description
•