1200856 - (CVE-2015-4520) CORS preflight cache poisoning with the credentials flag

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[(no longer active)]

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.

Comment 1

[(no longer active)]

Attachment: Fix the computation of CORS preflight cache keys

Comment 2

[(no longer active)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8ecd1ff453a

Comment 3

[(no longer active)]

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.

Comment 4

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Needs info to Liz for esr38 approval.

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b71af0ebe16c

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Approved for uplift to ESR38.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/534a3ae9faa1

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/549f54fa2333

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/774044a000d0

Comment 11

[Ryan VanderMeulen [:RyanVM]]

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

Comment 12

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/82f7bc868126