Bug 1200856 (CVE-2015-4520)

CORS preflight cache poisoning with the credentials flag

RESOLVED FIXED in Firefox 41

Status

()

defect
RESOLVED FIXED
4 years ago
2 months ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

({csectype-sop, sec-high})

unspecified
mozilla43
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox40 wontfix, firefox41+ fixed, firefox42+ fixed, firefox43+ fixed, firefox-esr31 wontfix, firefox-esr3841+ fixed, b2g-v2.0 wontfix, b2g-v2.0M wontfix, b2g-v2.1 wontfix, b2g-v2.1S fixed, b2g-v2.2 fixed, b2g-v2.2r fixed, b2g-master fixed)

Details

(Whiteboard: [post-critsmash-triage][adv-main41+][adv-esr38.3+])

Attachments

(1 attachment)

Assignee

Description

4 years ago
nsPreflightCache::GetCacheKey() has a bug that causes us to generate the same cache key for two preflight requests that only differ in the credentials flag.  This can cause us to bypass a CORS preflight in the following scenario:

* The page does an XHR without credentials which requires preflight.
* The preflight finishes successfully, and we store the result in the preflight cache.
* Before the cache entry expires, the page does an XHR with credentials but otherwise with the same preflight params as the first one.
* We mistakenly think that we have a preflight cache entry that allows us to connect to the remote server for the second XHR, and the page manages to send the XHR with credentials without a preflight.

Going back in the history, I think we have had this bug since forever.  It definitely predates bug 644476.  I didn't look back further.
Assignee

Updated

4 years ago
See Also: → 1200869
Assignee

Updated

4 years ago

Updated

4 years ago
Group: core-security → dom-core-security
Assignee

Comment 3

4 years ago
Comment on attachment 8655694 [details] [diff] [review]
Fix the computation of CORS preflight cache keys

[Security approval request comment]
How easily could an exploit be constructed based on the patch?  It depends.  If I land the patch as is here, it's trivial (especially with the test and the commit message.)  But I can also try to hide what this patch is doing some more by changing stuff around it and such, but a careful reader could probably figure out what the implications are...

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?  The tests obviously do, and I think we should not land the tests before the fix is shipped on the release channel.  I'm open to ideas for the commit message, such as "Make string manipulation faster" or something like that?

Which older supported branches are affected by this flaw? All branches.

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?  The backports are trivial and very low risk.

How likely is this patch to cause regressions; how much testing does it need?  I've tested it locally and on try and the problem is also quite well understood.  I'm not too much worried about regressions from this.
Attachment #8655694 - Flags: sec-approval?
Attachment #8655694 - Flags: approval‑mozilla‑b2g37_v2_2r?
Attachment #8655694 - Flags: approval-mozilla-release?
Attachment #8655694 - Flags: approval-mozilla-esr38?
Attachment #8655694 - Flags: approval-mozilla-esr31?
Attachment #8655694 - Flags: approval-mozilla-beta?
Attachment #8655694 - Flags: approval-mozilla-b2g37?
Attachment #8655694 - Flags: approval-mozilla-aurora?
Sec-approval+ to land on trunk without tests. We should take this on Aurora, Beta, and ESR38. ESR31 is at EOL so we don't need it there.
Attachment #8655694 - Flags: sec-approval?
Attachment #8655694 - Flags: sec-approval+
Attachment #8655694 - Flags: approval-mozilla-release?
Attachment #8655694 - Flags: approval-mozilla-esr31?
Attachment #8655694 - Flags: approval-mozilla-beta?
Attachment #8655694 - Flags: approval-mozilla-beta+
Attachment #8655694 - Flags: approval-mozilla-aurora?
Attachment #8655694 - Flags: approval-mozilla-aurora+
Assignee

Updated

4 years ago
Flags: in-testsuite?
Needs info to Liz for esr38 approval.
Flags: needinfo?(lhenry)
https://hg.mozilla.org/mozilla-central/rev/b71af0ebe16c
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Comment on attachment 8655694 [details] [diff] [review]
Fix the computation of CORS preflight cache keys

Approved for uplift to ESR38.
Flags: needinfo?(lhenry)
Attachment #8655694 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
Whiteboard: [post-critsmash-triage]
Comment on attachment 8655694 [details] [diff] [review]
Fix the computation of CORS preflight cache keys

sec-high don't need approval for B2G if they're fixed on affected Fx branches.

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c1ed0cd007f2
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2r/rev/c1ed0cd007f2
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/9d414eb53b23
Attachment #8655694 - Flags: approval‑mozilla‑b2g37_v2_2r?
Attachment #8655694 - Flags: approval-mozilla-b2g37?
Group: dom-core-security → core-security-release
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main41+][adv-esr38.3+]
Alias: CVE-2015-4520
Assignee

Comment 12

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/82f7bc868126
Flags: in-testsuite? → in-testsuite+
Group: core-security-release
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.