Firefox Site Isolation (Fission) Leaks Set-Cookie headers
Categories
(Core :: Networking: Cookies, enhancement)
Tracking
()
People
(Reporter: david, Unassigned)
Details
Steps to reproduce:
Tested using Firefox nightly (102.0a1).
- Navigate to
https://adobkin.name/coxp/leaktest.php?coep=require-corp&coop=same-originin Firefox.
This page has COOP+COEP enabled and tries to load a cross-origin image that doesn't set a CORP header. The image is blocked but response includes the header:
Set-Cookie: secret=SECRETchaed5eeCeiM5hee3ou9Ogi7ooMeeHou1ogaoy7moya9MewoXeanie1fa7OhHahd; Path=/; SameSite=None; Secure
-
Navigate to
about:memoryand click the 'Measure' button. Find the process corresponding to the previously opened page in the process index and copy the pid out of the title. In my case the process was called "webCOOP+COEP=https://adobkin.name". -
Dump render process memory. In the console, run
gcore -a $pid -
Run
grep -a SECRETchaed5eeCeiM5hee3ou9Ogi7ooMeeHou1ogaoy7moya9MewoXeanie1fa7OhHahd core.$pidto check if the value from the Set-Cookie header leaked into the renderer process (even though the response body was blocked by COEP)
Actual results:
The cookie value was leaked into the renderer process's memory where a Spectre-capable attacker could have stollen it
Expected results:
The cookie value should not be present in the renderer process's memory (this is how Chrome's site isolation behaves)
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: Cookies' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
We are already working on this.
Ed, can you please confirm or reopen?
I am able to replicate on fx 100.0.
I'm pretty sure this will be solved by bug 1713203 fix. I will attempt replication again after implementation is complete of cookie broadcast and re-open this bug if necessary.
Description
•