moz_bug_r_a4 Reporter
	Description • 12 years ago

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.

	moz_bug_r_a4 Reporter
	Comment 1 • 12 years ago

This is used to show document.referrer.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 3 • 12 years ago

Bobby, I have a gift for you :)

->bholley

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 4 • 12 years ago

Bobby - we're a few weeks into Aurora, have you had a chance to look into this yet?  Still viable candidate for 19 tracking?

	Bobby Holley (:bholley) Assignee
	Comment 5 • 12 years ago

(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.

	Bobby Holley (:bholley) Assignee
	Comment 6 • 12 years ago

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.

	Alex Keybl [:akeybl]
	Comment 7 • 12 years ago

(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?

	Bobby Holley (:bholley) Assignee
	Comment 8 • 12 years ago

(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.

	moz_bug_r_a4 Reporter
	Comment 9 • 11 years ago

The old testcase no longer works on trunk.  I'll attach a new testcase.

	Andrew McCreight [:mccr8]
	Comment 11 • 11 years ago

Any progress here, Bobby?

	Bobby Holley (:bholley) Assignee
	Comment 12 • 11 years ago

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?

	Boris Zbarsky [:bzbarsky]
	Comment 13 • 11 years ago

Not yet and no... We should get one filed.

	Bobby Holley (:bholley) Assignee
	Comment 14 • 11 years ago

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.

	Bobby Holley (:bholley) Assignee
	Comment 15 • 11 years ago

Actually, I think the aggregate of these issues is more likely to be sec-high. :-(

	Bobby Holley (:bholley) Assignee
	Comment 16 • 11 years ago

I've filed bug 951992 so that the work here can happen in public.

	Bobby Holley (:bholley) Assignee
	Comment 17 • 10 years ago

I think we can be a bit more precise about the deps - fixing.

	Bobby Holley (:bholley) Assignee
	Comment 18 • 10 years ago

The deps are now fixed, so I'm comfortable calling this fixed as well. \o/

	Daniel Veditz [:dveditz]
	Comment 20 • 10 years ago

Is it possible to port the fixes to ESR31?

	moz_bug_r_a4 Reporter
	Comment 21 • 10 years ago

I'll attach a new testcase so that we can verify the fix on ESR31.

	moz_bug_r_a4 Reporter
	Comment 22 • 10 years ago

This is fixed on fx >= 34, but not fixed on 33, 32, esr31, and esr24.

	Bobby Holley (:bholley) Assignee
	Comment 23 • 10 years ago

(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.

	Benjamin Kerensa [:bkerensa]
	Comment 24 • 10 years ago

(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?

	Matt Wobensmith [:mwobensmith][:matt:]
	Comment 25 • 10 years ago

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.

	Bobby Holley (:bholley) Assignee
	Comment 26 • 10 years ago

(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.

	Matt Wobensmith [:mwobensmith][:matt:]
	Comment 27 • 10 years ago

Thanks for the info and advice, Bobby.

Was this bug ever reproducible using these test files?

	Bobby Holley (:bholley) Assignee
	Comment 28 • 10 years ago

(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.

	moz_bug_r_a4 Reporter
	Comment 29 • 10 years ago

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.

	moz_bug_r_a4 Reporter
	Comment 30 • 10 years ago

I can reproduce this on fx33 and esr31.

	Matt Wobensmith [:mwobensmith][:matt:]
	Comment 31 • 10 years ago

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.

	Al Billings [:abillings - ex-MoCo]
	Comment 32 • 10 years ago

No 34 advisory because of embargo.