Entry and Incumbent settings objects can be spoofed when computed via the JSContext stack

VERIFIED FIXED in Firefox 34

Status

()

defect
VERIFIED FIXED
7 years ago
4 years ago

People

(Reporter: moz_bug_r_a4, Assigned: bobbyholley)

Tracking

({regression, sec-high})

Trunk
mozilla34
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18 unaffected, firefox19- wontfix, firefox33 wontfix, firefox34 verified, firefox35 verified, firefox36 verified, firefox-esr10 unaffected, firefox-esr17 unaffected, firefox-esr31 wontfix)

Details

(Whiteboard: [adv-main34-] Embargo until ESR-31 EOL)

Attachments

(5 attachments)

This is a regression from bug 809290.

While a script is running on a JSContext, the current document associated with the JSContext can be changed, thus it's possible to spoof document.referrer.
This is used to show document.referrer.
Posted file testcase
Bobby, I have a gift for you :)

->bholley
Assignee: nobody → bobbyholley+bmo
Flags: sec-bounty?
Bobby - we're a few weeks into Aurora, have you had a chance to look into this yet?  Still viable candidate for 19 tracking?
Flags: needinfo?(bobbyholley+bmo)
(In reply to Lukas Blakk [:lsblakk] from comment #4)
> Bobby - we're a few weeks into Aurora, have you had a chance to look into
> this yet?  Still viable candidate for 19 tracking?

I've been on PTO, but will look at it soon. Note that this also effectively exists in a different form on m-b and trunk, via bug 812546.
Flags: needinfo?(bobbyholley+bmo)
I've looked into this. The basic problem is that the JSContext isn't actually a great way to track the script entry point, because it's associated with the nsIScriptContext, which in turn is associated with the outer window.

So basically, we need to implement a proper html5 script entry point stack. I'm not sure exactly how much code this is going to be, but it's probably not backportable to beta. It _might_ be to aurora if I get it to it in time, but we'll have to see. I'm guessing we'll probably WONTFIX this for 19, but I'm going to see how much time I can make for this in the coming weeks.
(In reply to Bobby Holley (:bholley) from comment #6)
> So basically, we need to implement a proper html5 script entry point stack.
> I'm not sure exactly how much code this is going to be, but it's probably
> not backportable to beta. It _might_ be to aurora if I get it to it in time,
> but we'll have to see. I'm guessing we'll probably WONTFIX this for 19, but
> I'm going to see how much time I can make for this in the coming weeks.

This was internally reported sec-moderate and FF19 is now on beta. Are we at the point where we'd like to WONTFIX?
(In reply to Alex Keybl [:akeybl] from comment #7)

> This was internally reported sec-moderate and FF19 is now on beta. Are we at
> the point where we'd like to WONTFIX?

Yep. I've been assigned to b2g until the end of this week pending major security catastrophes. Also, the machinery for to fix this bug properly is likely to be nontrivial, so it won't be all that backportable. This is likely to be WONTFIX for several releases.
The old testcase no longer works on trunk.  I'll attach a new testcase.
Posted file testcase 2
Any progress here, Bobby?
Flags: needinfo?(bobbyholley+bmo)
This depends on having a real script entry point stack, which IIRC Boris was going to start on. bz, any status there? Is there a dependent bug?
Flags: needinfo?(bobbyholley+bmo) → needinfo?(bzbarsky)
Not yet and no... We should get one filed.
Flags: needinfo?(bzbarsky)
We can fix this now - I'm doing it in bug 887928.

However, this bug is _really_ about the fact that any consumer of GetDynamicScriptGlobal can be spoofed. It's hard to know which ones are security-sensitive, but sec-moderate seems like a decent hand-wavy guess for the issue as a whole.

Updating the bug title. We can close this when we get rid of all of the consumers of GetDynamicScriptContext and friends.
Summary: It's possible to spoof document.referrer → Entry and Incumbent settings objects can be spoofed when computed via the JSContext stack
Depends on: 887928
Actually, I think the aggregate of these issues is more likely to be sec-high. :-(
Keywords: sec-moderatesec-high
I've filed bug 951992 so that the work here can happen in public.
Depends on: 951992
No longer depends on: 887928
Group: dom-core-security
I think we can be a bit more precise about the deps - fixing.
Depends on: 1056271, 796938
No longer depends on: 951992
The deps are now fixed, so I'm comfortable calling this fixed as well. \o/
No longer blocks: 809290
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Group: dom-core-security
Duplicate of this bug: 812546
Is it possible to port the fixes to ESR31?
Blocks: 809290
Flags: needinfo?(bobbyholley)
I'll attach a new testcase so that we can verify the fix on ESR31.
This is fixed on fx >= 34, but not fixed on 33, 32, esr31, and esr24.
(In reply to Daniel Veditz [:dveditz] from comment #20)
> Is it possible to port the fixes to ESR31?

That would be an insane amount of work, because we'd need to backport a ton of stuff - see in particular all the dependencies of bug 951991. I think we should just embargo this on esr.
Flags: needinfo?(bobbyholley)
(In reply to Daniel Veditz [:dveditz] from comment #20)
> Is it possible to port the fixes to ESR31?

If you are ok with bholley's proposal can we wontfix this for ESR31?
Flags: needinfo?(dveditz)
Depends on: 951991
Flags: needinfo?(dveditz)
Whiteboard: Embargo until ESR-31 EOL
I've tried all three bug files using affected browsers ranging from Fx19 through pre-fix Fx34, and I have not been able to reproduce the original issue. Did something change externally that would affect these tests? In any case, if you could run your tests again, let us know if the issue has been fixed on your end. Thank you.
Flags: needinfo?(moz_bug_r_a4)
(In reply to Matt Wobensmith from comment #25)
> I've tried all three bug files using affected browsers ranging from Fx19
> through pre-fix Fx34, and I have not been able to reproduce the original
> issue. Did something change externally that would affect these tests? In any
> case, if you could run your tests again, let us know if the issue has been
> fixed on your end. Thank you.

This is probably because the specific behavior here from bug 809290 was reverted in bug 887928 for spec reasons.

The underlying issue here is a very deep conceptual one, and I don't think it benefits much from QA verification.
Thanks for the info and advice, Bobby.

Was this bug ever reproducible using these test files?
(In reply to Matt Wobensmith from comment #27)
> Thanks for the info and advice, Bobby.
> 
> Was this bug ever reproducible using these test files?

presumably yes when moz_bug_r_a4 filed them.
Testcase 1 and 2 were fixed by bug 887928. The reason testcase 3 no longer works is that the page used as referrer no longer allows framing. I'll attach a new testcase that does not use a subframe.
Flags: needinfo?(moz_bug_r_a4)
Posted file testcase 4
I can reproduce this on fx33 and esr31.
Thanks moz_bug_r_a4, your test worked great, and I reproduced it on Fx33. Much appreciated.

Verified fixed on Fx34, Fx35, Fx36, 2014-11-19.
No 34 advisory because of embargo.
Whiteboard: Embargo until ESR-31 EOL → [adv-main34-] Embargo until ESR-31 EOL
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.