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

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[moz_bug_r_a4]

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.

Comment 1

[moz_bug_r_a4]

Attachment: show document.referrer

This is used to show document.referrer.

Comment 2

[moz_bug_r_a4]

Attachment: testcase

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Bobby, I have a gift for you :)

->bholley

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 5

[Bobby Holley (:bholley)]

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

Comment 6

[Bobby Holley (:bholley)]

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.

Comment 7

[Alex Keybl [:akeybl]]

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

Comment 8

[Bobby Holley (:bholley)]

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

Comment 9

[moz_bug_r_a4]

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

Comment 10

[moz_bug_r_a4]

Attachment: testcase 2

Comment 11

[Andrew McCreight [:mccr8]]

Any progress here, Bobby?

Comment 12

[Bobby Holley (:bholley)]

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?

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[Bobby Holley (:bholley)]

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.

Comment 15

[Bobby Holley (:bholley)]

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

Comment 16

[Bobby Holley (:bholley)]

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

Comment 17

[Bobby Holley (:bholley)]

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

Comment 18

[Bobby Holley (:bholley)]

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

Comment 20

[Daniel Veditz [:dveditz]]

Is it possible to port the fixes to ESR31?

Comment 21

[moz_bug_r_a4]

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

Comment 22

[moz_bug_r_a4]

Attachment: testcase 3 - window.open

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

Comment 23

[Bobby Holley (:bholley)]

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

Comment 24

[Benjamin Kerensa [:bkerensa]]

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

Comment 25

[Matt Wobensmith [:mwobensmith][:matt:]]

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.

Comment 26

[Bobby Holley (:bholley)]

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

Comment 27

[Matt Wobensmith [:mwobensmith][:matt:]]

Thanks for the info and advice, Bobby.

Was this bug ever reproducible using these test files?

Comment 28

[Bobby Holley (:bholley)]

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

Comment 29

[moz_bug_r_a4]

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.

Comment 30

[moz_bug_r_a4]

Attachment: testcase 4

I can reproduce this on fx33 and esr31.

Comment 31

[Matt Wobensmith [:mwobensmith][:matt:]]

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.

Comment 32

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

No 34 advisory because of embargo.