Closed Bug 497102 Opened 12 years ago Closed 12 years ago
Bypassing XOW by using a shallow XPCNative
Wrapper and a numeric property
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...
I'll write some tests in a jiffy.
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?
(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.
Status: ASSIGNED → RESOLVED
Closed: 12 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]
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: approval184.108.40.206?
Attachment #382366 - Flags: approval220.127.116.11? → approval18.104.22.168+
Comment on attachment 382366 [details] [diff] [review] Proposed fix Approved for 22.214.171.124, 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
Verified for 126.96.36.199 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/2009063005 GranParadiso/3.0.12pre (.NET CLR 3.5.30729) using testcase. Verified bug in 3.0.11.
Status: RESOLVED → VERIFIED
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.