369211 - content can pollute implicit XPCNativeWrapper

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[shutdown]

Attachment: testcase

Implicit XPCNativeWrapper, a wrapper object to provide a safe way to access
untrusted content DOM from chrome, can be polluted by that untrusted content.

steps:
1. load the attached testcase.
2. middle click on the content to start auto scrolling.
3. you will see an alert if there is a bug.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.2pre)
 Gecko/20070203 BonEcho/2.0.0.2pre

Comment 1

[Johnny Stenback (:jst)]

This is basically another variant of what's discussed in bug 363891. Content fools chrome code into calling eval indirectly, and gets it to eval untrusted script from chrome.

Comment 2

[Johnny Stenback (:jst)]

While the testcase in this bug is fixed by mrbkap's eval() changes we think it's still vulnerable to alternatives. Reassigning to mrbkap for him to have a deeper look at this.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

In particular, we were wondering if we could replace 'eval' with a location setter, or something, which would allow similar access to the implicit XPCNativeWrapper. I'm CCing moz_bug_r_a4 since he seems to eat these sort of testcases for breakfast.

Comment 4

[moz_bug_r_a4]

Attachment: testcase 2

It's possible to use 'eval' with a window.

(If I replace 'eval' with a location setter, |window[0].parent.document| is not
the implicit XPCNativeWrapper.)

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

This patch is a bit of a hack but it works. The main problem here is that the script that eval creates inherits its scripted caller's script filename. Because of this, even though we find the right principals for the script, we still think that it's from the chrome XBL binding. This patch makes us use the codebase of the principals that we're using if we didn't end up using the caller's. I'm hoping that this situation is rare enough that nobody is going to care.

Comment 6

[Brendan Eich [:brendan]]

Comment on attachment 268528 [details] [diff] [review]
Proposed fix

r=me, wondering what the possible values of principals->codebase, e.g., for the system principal?

/be

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

I looked into this, and the system principal uses the string "[System Principal]" for its codebase. It's not a great filename, but I don't think that we can get into this codepath with the system principal anyway.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

I noticed that this doesn't have security markings ([sg:*]) but is in the security group. These two facts seem disjoint to me.

Comment 9

[Daniel Veditz [:dveditz]]

As a member of the security group feel free to take your best shot at a sg: marking without waiting for me to do it. Your evaluation is likely to involve less guessing than mine.

Is this OK to take on branch?

Comment 10

[Damon Sicore (:damons)]

Test for this in test suite?  What's the process for adding tests for sg: bugs?

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 268528 [details] [diff] [review]
Proposed fix

This applies to the 1.8 and 1.8.0 branches as-is.

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 268528 [details] [diff] [review]
Proposed fix

approved for 1.8.1.5 and 1.8.0.13, a=dveditz

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into the 1.8 branches.

Comment 14

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.5 using Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.5) Gecko/2007071216 Firefox/2.0.0.5 and the testcases from this bug.

Comment 15

[juan becerra [:juanb]]

Verified on Thunderbird version 1.5.0.13 (20070809) on an XP (vm) with testcases in comment #0 and comment #4.