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

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect)

Description

[tavin.cole]

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

Comment 1

[Frank Wein [:mcsmurf]]

Can you attach a testcase?

Comment 2

[Tanner M. Young [:tmyoung]]

Is this crash still reproducible in Firefox 3.5?  If it isn't, we should resolve it as RESOLVED WORKSFORME.

Comment 3

[Andreas Wuest]

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

[Andreas Wuest]

Attachment: 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

[Andreas Wuest]

Attachment: 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

[Andreas Wuest]

(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.

Comment 7

[Andreas Wuest]

And this is the crash report: http://crash-stats.mozilla.com/report/index/453cfa00-e000-4acc-a6d0-61d622090819

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Confirming based on comment 7. I'll take a look at this.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

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

[Andreas Wuest]

(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

[Wladimir Palant]

I think denying access to wrappedJSObject is what I would expect from nsISecurityCheckedComponent.

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Patch

I've had this lying in my patch queue for months now.

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 416838 [details] [diff] [review]
Patch

r=dveditz

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/6aeadfc80c1d

Comment 16

[Labuzov Dmitriy]

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

[Labuzov Dmitriy]

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

Comment 18

[Daniel Veditz [:dveditz]]

Comment on attachment 416838 [details] [diff] [review]
Patch

Approved for 1.9.2.10, a=dveditz for release-drivers

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 416838 [details] [diff] [review]
Patch

missed the 1.9.2.11 release, try for 1.9.2.12

Comment 20

[Labuzov Dmitriy]

tried in 1.9.2.12 - still not fixed :(

Comment 21

[timeless]

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.

Comment 22

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a2ba0dadb910

Comment 23

[Al Billings [:abillings - ex-MoCo]]

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/.