content can pollute implicit XPCNativeWrapper

RESOLVED FIXED

Status

()

Core
Security
--
major
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: shutdown, Assigned: mrbkap)

Tracking

({verified1.8.0.13, verified1.8.1.5})

Trunk
x86
Windows XP
verified1.8.0.13, verified1.8.1.5
Points:
---
Bug Flags:
blocking1.9 +
blocking1.8.1.5 +
wanted1.8.1.x +
blocking1.8.0.13 +
wanted1.8.0.x +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate?] keep private until 363891 fixed on branch. severity would depend on what the chrome in question was doing)

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
Created attachment 253882 [details]
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
Flags: blocking1.9?
Assignee: dveditz → jst
Flags: blocking1.9? → blocking1.9+
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.

Updated

10 years ago
Depends on: 363891
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.
Assignee: jst → mrbkap
(Assignee)

Comment 3

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

10 years ago
Created attachment 268472 [details]
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.)
(Assignee)

Comment 5

10 years ago
Created attachment 268528 [details] [diff] [review]
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.
Attachment #268528 - Flags: review?(brendan)
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED
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
Attachment #268528 - Flags: review?(brendan) → review+
(Assignee)

Comment 7

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

Comment 8

10 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
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?
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Whiteboard: [sg:moderate?] severity would depend on what the chrome in question was doing
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Test for this in test suite?  What's the process for adding tests for sg: bugs?
Flags: in-testsuite?
(Assignee)

Comment 11

10 years ago
Comment on attachment 268528 [details] [diff] [review]
Proposed fix

This applies to the 1.8 and 1.8.0 branches as-is.
Attachment #268528 - Flags: approval1.8.1.5?
Attachment #268528 - Flags: approval1.8.0.13?
Comment on attachment 268528 [details] [diff] [review]
Proposed fix

approved for 1.8.1.5 and 1.8.0.13, a=dveditz
Attachment #268528 - Flags: approval1.8.1.5?
Attachment #268528 - Flags: approval1.8.1.5+
Attachment #268528 - Flags: approval1.8.0.13?
Attachment #268528 - Flags: approval1.8.0.13+
(Assignee)

Comment 13

10 years ago
Fix checked into the 1.8 branches.
Keywords: fixed1.8.0.13, fixed1.8.1.5
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.
Keywords: fixed1.8.1.5 → verified1.8.1.5
Verified on Thunderbird version 1.5.0.13 (20070809) on an XP (vm) with testcases in comment #0 and comment #4. 
Keywords: fixed1.8.0.13 → verified1.8.0.13
Whiteboard: [sg:moderate?] severity would depend on what the chrome in question was doing → [sg:moderate?] keep private until 363891 fixed on branch. severity would depend on what the chrome in question was doing
Group: core-security
You need to log in before you can comment on or make changes to this bug.