Closed Bug 497102 Opened 11 years ago Closed 11 years ago

Bypassing XOW by using a shallow XPCNativeWrapper and a numeric property

Categories

(Core :: Security, defect)

x86
Windows XP
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

Details

(Keywords: fixed1.9.1, verified1.9.0.12, Whiteboard: [sg:high])

Attachments

(1 file)

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.
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:
I'm not sure why -- it's a real bug...
Attached patch Proposed fixSplinter Review
I'll write some tests in a jiffy.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #382366 - Flags: superreview?(bzbarsky)
Attachment #382366 - Flags: review?(bzbarsky)
Flags: blocking1.9.1?
Flags: blocking1.9.0.12?
Attachment #382366 - Flags: superreview?(bzbarsky)
Attachment #382366 - Flags: superreview+
Attachment #382366 - Flags: review?(bzbarsky)
Attachment #382366 - Flags: review+
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?
Flags: blocking1.9.1? → blocking1.9.1+
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?
Whiteboard: [needs landing]
Flags: wanted1.9.1.x+
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x-
Flags: blocking1.9.0.12?
Flags: blocking1.9.0.12+
(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.
http://hg.mozilla.org/mozilla-central/rev/2891ea9fed97
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
This landed fine, please get it on mozilla-1.9.1 ASAP.
Whiteboard: [needs 1.9.1 landing]
Blake: Does this patch apply to 1.9.0? If so, can you request approval on it?
Whiteboard: [needs new patch?]
Comment on attachment 382366 [details] [diff] [review]
Proposed fix

dom/base -> dom/src/base, but otherwise this applies.
Attachment #382366 - Flags: approval1.9.0.12?
Whiteboard: [needs new patch?]
Attachment #382366 - Flags: approval1.9.0.12? → approval1.9.0.12+
Comment on attachment 382366 [details] [diff] [review]
Proposed fix

Approved for 1.9.0.12, a=dveditz for release-drivers
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
Keywords: fixed1.9.0.12
Whiteboard: [sg:high]
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.
Status: RESOLVED → VERIFIED
Group: core-security
Where is comment 1? Why is it hidden?
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.
(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?
You need to log in before you can comment on or make changes to this bug.