Last Comment Bug 497102 - Bypassing XOW by using a shallow XPCNativeWrapper and a numeric property
: Bypassing XOW by using a shallow XPCNativeWrapper and a numeric property
Status: VERIFIED FIXED
: [sg:high]
: fixed1.9.1, verified1.9.0.12
Product: Core
Classification: Components
Component: Security
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap)
: toolkit
:
:
:
  Show dependency treegraph
 
Reported: 2009-06-09 07:51 PDT by moz_bug_r_a4
Modified: 2009-07-23 04:58 PDT (History)
10 users (show)
mbeltzner: blocking1.9.1+
dveditz: wanted1.9.1.x+
dveditz: blocking1.9.0.12+
dveditz: wanted1.9.0.x+
dveditz: wanted1.8.1.x-
See Also:
Crash Signature:


Attachments
Proposed fix (1.14 KB, patch)
2009-06-09 13:43 PDT, Blake Kaplan (:mrbkap)
bzbarsky: review+
bzbarsky: superreview+
dveditz: approval1.9.0.12+
Details | Diff | Splinter Review

Summon comment box

Description moz_bug_r_a4 2009-06-09 07:51:56 PDT
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 2009-06-09 11:05:59 PDT
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) 2009-06-09 13:41:53 PDT
I'm not sure why -- it's a real bug...
Comment 4 Blake Kaplan (:mrbkap) 2009-06-09 13:43:11 PDT
Created attachment 382366 [details] [review]
Proposed fix

I'll write some tests in a jiffy.
Comment 5 Boris Zbarsky (:bz) 2009-06-09 18:28:43 PDT
Comment on attachment 382366 [details] [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] 2009-06-10 14:40:37 PDT
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 2009-06-10 15:24:40 PDT
(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) 2009-06-10 15:44:01 PDT
http://hg.mozilla.org/mozilla-central/rev/2891ea9fed97
Comment 9 Mike Beltzner [:beltzner] 2009-06-10 22:31:00 PDT
This landed fine, please get it on mozilla-1.9.1 ASAP.
Comment 10 Olli Pettay [:smaug] 2009-06-11 01:40:52 PDT
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1541e172b6f2
Comment 11 Samuel Sidler (old account; do not CC) 2009-06-16 07:57:34 PDT
Blake: Does this patch apply to 1.9.0? If so, can you request approval on it?
Comment 12 Blake Kaplan (:mrbkap) 2009-06-16 12:29:42 PDT
Comment on attachment 382366 [details] [review]
Proposed fix

dom/base -> dom/src/base, but otherwise this applies.
Comment 13 Daniel Veditz 2009-06-16 15:35:25 PDT
Comment on attachment 382366 [details] [review]
Proposed fix

Approved for 1.9.0.12, a=dveditz for release-drivers
Comment 14 Blake Kaplan (:mrbkap) 2009-06-23 20:17:30 PDT
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] 2009-06-30 11:34:32 PDT
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) 2009-07-22 08:22:57 PDT
Where is comment 1? Why is it hidden?
Comment 17 Daniel Veditz 2009-07-22 12:04:45 PDT
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) 2009-07-23 04:58:29 PDT
(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?

Note You need to log in before you can comment on or make changes to this bug.