497102 - Bypassing XOW by using a shallow XPCNativeWrapper and a numeric property

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[moz_bug_r_a4]

When a numeric property of a window is accessed and the numeric property is a
subframe, nsWindowSH::GetProperty does not call nsXPConnect::GetXOWForObject. 
Thus, it's possible to bypass XOW by using a shallow XPCNativeWrapper.

Comment 2

[Daniel Veditz [:dveditz]]

I've not been able to reproduce this with Gran Paradiso, Shiretoko or Minefield, and I don't see any Error Console messages that give me any clues why it's not working. I also tried loading this from a file:// URI but not plain http:

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

I'm not sure why -- it's a real bug...

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

I'll write some tests in a jiffy.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 382366 [details] [diff] [review]
Proposed fix

This looks fine, esp with tests, but I thought we'd changed classinfo to allow wrappers in WrapNative.  What happened to that patch?

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Blake: can you please land this in mozilla-central and assuming it goes green there, on mozilla-1.9.1? If you can't get to it, can you find someone else to do it for you?

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #2)
> I've not been able to reproduce this ...

In a different test profile I can now reproduce, will try to figure out what pref changes make the difference.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/2891ea9fed97

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

This landed fine, please get it on mozilla-1.9.1 ASAP.

Comment 10

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

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1541e172b6f2

Comment 11

[Samuel Sidler (old account; do not CC)]

Blake: Does this patch apply to 1.9.0? If so, can you request approval on it?

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 382366 [details] [diff] [review]
Proposed fix

dom/base -> dom/src/base, but otherwise this applies.

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 382366 [details] [diff] [review]
Proposed fix

Approved for 1.9.0.12, a=dveditz for release-drivers

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

Checking in dom/src/base/nsDOMClassInfo.cpp;
/cvsroot/mozilla/dom/src/base/nsDOMClassInfo.cpp,v  <--  nsDOMClassInfo.cpp
new revision: 1.552; previous revision: 1.551
done

Comment 15

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

Verified for 1.9.0.12 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.12pre) Gecko/2009063005 GranParadiso/3.0.12pre (.NET CLR 3.5.30729) using testcase. Verified bug in 3.0.11.

Comment 16

[Bartłomiej Brzozowiec (BartZilla)]

Where is comment 1? Why is it hidden?

Comment 17

[Daniel Veditz [:dveditz]]

As a matter of policy we no longer publish working exploits -- when we do we just see them show up on websites trying to nab people who haven't upgraded yet. Testcases that demonstrate a flaw (e.g. a crash) without containing a working exploit we do usually publish, with trepidation because sometimes those, too, show up on places like milw0rm with an added payload -- but the ability to run regression tests outweighs that particular risk.

Comment 1 is just a link to the hidden testcase, and it's only private to add an extra layer of security so someone can't target that attachment number should there be a bugzilla breach.

Comment 18

[Bartłomiej Brzozowiec (BartZilla)]

(In reply to comment #17)
> As a matter of policy we no longer publish working exploits (...).

Is this policy written somewhere? I don't see this exact statement here: http://www.mozilla.org/projects/security/security-bugs-policy.html
Could you point me to some public discussion that led to the formulation of this policy (ie. "we no longer publish working exploits")?

Does this mean that comment 1 / attachment with testcase will be hidden forever?