segfault crash accessing wrapped
JSObject for an ns ISecurity Checked Component [@ ns Script Security Manager::Check Property Access Impl(unsigned int, ns AXPCNative Call Context*, JSContext*, JSObject*, ns ISupports*, ns IURI*, ns IClass Info*, char const*, int, void**)
412 bytes, text/html
1.37 KB, patch
|Details | Diff | Splinter Review|
Component: General → XPConnect
Product: Firefox → Core
QA Contact: general → xpconnect
Version: unspecified → 1.8 Branch
Can you attach a testcase?
Is this crash still reproducible in Firefox 3.5? If it isn't, we should resolve it as RESOLVED WORKSFORME.
I can confirm this bug on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20090729 Firefox/3.5.2. What's worse, there is an extension in the wild that indeed sets wrappedJSObject in its ctor (although it never actually tries to access it), which means that users of this extension are vulnerable to a denial-of-service attack. I am not going to disclose the name of the extension as long as this bug is world-readable, but the extension is offered as part of a well-known web application, and helps users interact with said web application.
Created attachment 395401 [details] Component that sets wrappedJSObject A component that sets wrappedJSObject to itself in its constructor. It exposes itself as a global constructor, so content can access it. This is basically a stripped down version of the extension in the wild.
Created attachment 395402 [details] HTML page that calls the component on button click The HTML page contains a button that instantiates a CrashMe object and then accesses wrappedJSObject on it. Put the component somewhere the browser can find it (e.g. some extension's components directory -- don't forget to force component re-registration after that by removing compreg.dat from your profile and then restarting the browser), and then load the HTML page.
(In reply to comment #3) > [..] the extension is offered as part of a well-known web > application, and helps users interact with said web application. I should mention that this extension is a JS global constructor (just like the test case I've attached), so the DOS attack can be carried out remotely from any malicious website.
And this is the crash report: http://crash-stats.mozilla.com/report/index/453cfa00-e000-4acc-a6d0-61d622090819
Confirming based on comment 7. I'll take a look at this.
Assignee: nobody → mrbkap
Status: UNCONFIRMED → NEW
Ever confirmed: true
Andreas, what is the expected behavior of your testcase? With a fix for the crash, we now throw an exception, not being allowed to access .wrappedJSObject on a JS-implemented component.
(In reply to comment #9) > Andreas, what is the expected behavior of your testcase? With a fix for the > crash, we now throw an exception, not being allowed to access .wrappedJSObject > on a JS-implemented component. I am unsure whether an exception or a simple |undefined| would be the expected behaviour. You better ask somebody who's a bit more involved with wrappers than me about that. As long as |wrappedJSContent| is inaccessible from content I am happy.
I think denying access to wrappedJSObject is what I would expect from nsISecurityCheckedComponent.
Created attachment 416838 [details] [diff] [review] Patch I've had this lying in my patch queue for months now.
Attachment #416838 - Flags: review?(dveditz)
Component: XPConnect → Security: CAPS
QA Contact: xpconnect → caps
Summary: segfault crash accessing wrappedJSObject for an nsISecurityCheckedComponent → segfault crash accessing wrappedJSObject for an nsISecurityCheckedComponent [@ nsScriptSecurityManager::CheckPropertyAccessImpl(unsigned int, nsAXPCNativeCallContext*, JSContext*, JSObject*, nsISupports*, nsIURI*, nsIClassInfo*, char const*, int, void**)
Comment on attachment 416838 [details] [diff] [review] Patch r=dveditz
Attachment #416838 - Flags: review?(dveditz) → review+
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
This patch is not applied to mozilla-1.9.2 (Branch development on Firefox 3.6 and Gecko 1.9.2). See here: http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/c07c6c1b5071/caps/src/nsScriptSecurityManager.cpp#l793
Is it possible to fix this bug in /mozilla-1.9.2 branch ?
Comment on attachment 416838 [details] [diff] [review] Patch Approved for 184.108.40.206, a=dveditz for release-drivers
Attachment #416838 - Flags: approval220.127.116.11? → approval18.104.22.168+
Comment on attachment 416838 [details] [diff] [review] Patch missed the 22.214.171.124 release, try for 126.96.36.199
tried in 188.8.131.52 - still not fixed :(
Dmitriy: the bug doesn't claim to be fixed in 184.108.40.206, please don't spam bugs with useless comments. if you need help understanding a bug's state, please try a support channel.
status1.9.2: --- → .13-fixed
This should be fixed now in 1.9.2. It can be checked with a nightly 1.9.2 build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/.
Whiteboard: [sg:dos] → [sg:dos] [qa-examined-192]
You need to log in before you can comment on or make changes to this bug.