ContentParent::RecvSessionHistoryUpdate should not work outside of automation
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox86 | --- | wontfix |
firefox87 | --- | wontfix |
firefox88 | --- | fixed |
People
(Reporter: mccr8, Assigned: smaug)
References
(Blocks 1 open bug)
Details
(Keywords: sec-moderate, Whiteboard: [post-critsmash-triage][adv-main88+])
Attachments
(2 files)
I noticed that there's a PContent message SessionHistoryUpdate with the comment "This is a temporary way to pass index and length through parent process. Used for testing." It looks like what this does is reflect the session history update being sent from the child process back to other children in the same browsing context group, which may not be in the same process.
This seems potentially bad in the case where a child process gets taken over. I haven't found any particular place where this could cause an out of bounds memory access, but maybe manipulating the session history is enough. It also is probably not good that this session history update information coming from the parent needs to be treated as potentially hostile, which people reading code might not expect.
I'm not exactly sure how this could be addressed. Maybe enough time has passed that this message can be removed, or maybe we can have it be ignored (and not sent) when we're not in a testing environment?
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
That code will go away. It was added to test the new setup for async index and length handling. But I can't see where it could cause any issues.
Assignee | ||
Updated•4 years ago
|
Comment 2•4 years ago
|
||
But I can't see where it could cause any issues.
That depends on what the value is used for, and what it could do if a compromised child passed a crafted value back to the parent.
Reporter | ||
Comment 3•4 years ago
|
||
The processes being sent to are in the same browsing context group, so I guess in the worst case imaginable (say, the message magically allows arbitrary execution) it won't have any real impact on non-Fission, and only make Fission as bad as non-Fission, so I'm not sure what the right rating would be.
Comment 4•4 years ago
|
||
Tracking this with the rest of fission sessionHistory work. Let's fix this by Fission M7a.
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
Updated•4 years ago
|
![]() |
||
Comment 6•4 years ago
|
||
remove the testing only code for history.length handling, r=peterv
https://hg.mozilla.org/integration/autoland/rev/c47401d2b91a5e59b34aa6a97d0f6995687dfff3
https://hg.mozilla.org/mozilla-central/rev/c47401d2b91a
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Updated•4 years ago
|
Updated•3 years ago
|
Description
•