segfault crash accessing wrappedJSObject for an nsISecurityCheckedComponent [@ nsScriptSecurityManager::CheckPropertyAccessImpl(unsigned int, nsAXPCNativeCallContext*, JSContext*, JSObject*, nsISupports*, nsIURI*, nsIClassInfo*, char const*, int, void**)

RESOLVED FIXED

Status

()

--
critical
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: tavin.cole, Assigned: mrbkap)

Tracking

({crash, testcase})

1.9.2 Branch
crash, testcase
Points:
---

Firefox Tracking Flags

(status1.9.2 .13-fixed, status1.9.1 wontfix)

Details

(Whiteboard: [sg:dos] [qa-examined-192])

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070115 Firefox/1.5.0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070115 Firefox/1.5.0.9

make an XPCOM component in javascript that sets this.wrappedJSObject = this in the constructor.  implement nsISecurityCheckedComponent.  get an instance in other javascript.  get the wrappedJSObject.  watch all firefox windows vanish :)

note:  i did this from untrusted javascript that got the instance because it was a javascript global property.  i don't know if that makes a difference.


Reproducible: Always
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.

Comment 3

10 years ago
I can confirm this bug on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) 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.

Comment 4

10 years ago
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.

Comment 5

10 years ago
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.

Comment 6

10 years ago
(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.
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.

Comment 10

10 years ago
(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.

Comment 11

10 years ago
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)

Updated

9 years ago
Component: XPConnect → Security: CAPS
Keywords: crash
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**)
Keywords: testcase
Whiteboard: [sg:dos]
Comment on attachment 416838 [details] [diff] [review]
Patch

r=dveditz
Attachment #416838 - Flags: review?(dveditz) → review+
http://hg.mozilla.org/mozilla-central/rev/6aeadfc80c1d
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Duplicate of this bug: 546845

Comment 16

9 years ago
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

Comment 17

9 years ago
Is it possible to fix this bug in /mozilla-1.9.2 branch ?

Updated

9 years ago
Attachment #416838 - Flags: approval1.9.2.10?
Comment on attachment 416838 [details] [diff] [review]
Patch

Approved for 1.9.2.10, a=dveditz for release-drivers
Attachment #416838 - Flags: approval1.9.2.10? → approval1.9.2.10+
Comment on attachment 416838 [details] [diff] [review]
Patch

missed the 1.9.2.11 release, try for 1.9.2.12
Attachment #416838 - Flags: approval1.9.2.12+
Attachment #416838 - Flags: approval1.9.2.11-
Attachment #416838 - Flags: approval1.9.2.11+

Updated

9 years ago
Keywords: checkin-needed

Comment 20

8 years ago
tried in 1.9.2.12 - still not fixed :(

Comment 21

8 years ago
Dmitriy: the bug doesn't claim to be fixed in 1.9.2.12, please don't spam bugs with useless comments. if you need help understanding a bug's state, please try a support channel.

Updated

8 years ago
Keywords: checkin-needed
Version: 1.8 Branch → 1.9.2 Branch
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]
status1.9.1: --- → wontfix
You need to log in before you can comment on or make changes to this bug.