Closed Bug 384750 Opened 17 years ago Closed 17 years ago

Arbitrary code execution by polluting implicit XPCNativeWrapper (without using eval)

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

References

Details

(Keywords: verified1.8.1.13, Whiteboard: [sg:critical] Need 1.8 patch, needs bug 387390 also)

Attachments

(1 file, 2 obsolete files)

Fixing Ts
(deleted), patch
jst
: review+
jst
: superreview+
dveditz
: approval1.8.1.13+
asac
: approval1.8.0.next?
Details | Diff | Splinter Review
Please see bug 369211. Content can access implicit XPCNativeWrappers without using eval(), by abusing tabbrowser.xml's |contentWindow| and |contentDocument| getter functions.
Attached file (deleted) —
So, at this point, I think the easiest way to fix these is to ensure that the callee has access to the XPCNativeWrapper in the XPCNativeWrapper code itself. I'll come up with a POC patch tomorrow or Monday, but I was wondering if there were better ideas.
Assignee: dveditz → nobody
Component: Security → DOM
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
OS: Windows XP → All
QA Contact: toolkit → general
Hardware: PC → All
Whiteboard: [sg:critical]
Version: unspecified → 1.8 Branch
Assignee: nobody → mrbkap
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Attached patch Proposed fix (obsolete) (deleted) — — Splinter Review
This stops the testcase, since any activity on an implicit native wrapper by non-system code is disallowed.
Attachment #270113 - Flags: review?(jst)
Attached patch Patch that starts (obsolete) (deleted) — — Splinter Review
The last patch didn't allow the browser to start. I'm not sure why I didn't see that before, though. This allows access to implicit wrappers with no JS on the stack (which happens when we seal the XPCNativeWrapper prototype on scope creation).
Attachment #270113 - Attachment is obsolete: true
Attachment #270208 - Flags: review?(jst)
Attachment #270113 - Flags: review?(jst)
Attachment #270208 - Flags: superreview+
Attachment #270208 - Flags: review?(jst)
Attachment #270208 - Flags: review+
Fix checked into trunk.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
I had to back this out (sigh), Ts doesn't work with it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch Fixing Ts (deleted) — — Splinter Review
The problem was that we were initializing classes with random JS on the stack. This fixes that problem by setting aside whatever JS is currently running while we initialize XPConnect classes. I don't think that there's a security problem with this, since we're controlling everything that happens during class initialization.
Attachment #270208 - Attachment is obsolete: true
Attachment #270663 - Flags: superreview?(jst)
Attachment #270663 - Flags: review?(jst)
Attachment #270663 - Flags: superreview?(jst)
Attachment #270663 - Flags: superreview+
Attachment #270663 - Flags: review?(jst)
Attachment #270663 - Flags: review+
Fix checked into trunk.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Blocks: 387053
No longer blocks: 387053
Depends on: 387053
Flags: in-testsuite-
Depends on: 387084
Let's see if we can get a test in our test suite for this.
Flags: in-testsuite- → in-testsuite?
Blocks: 387390
Flags: blocking1.8.1.5+ → blocking1.8.1.6+
Flags: blocking1.8.0.13+ → blocking1.8.0.14+
Do we still want this in 1.8.1.8, or should we wait until bug 387390 is also fixed (circumventing this fix)? If we land this we need to include the regression fixes, right?
Given this patch can be circumvented we'll wait for the real fix in the next update
Flags: blocking1.8.1.8+ → blocking1.8.1.9+
Whiteboard: [sg:critical] → [sg:critical] needs bug 387390 also
Flags: blocking1.8.0.14+ → blocking1.8.0.15+
Flags: blocking1.8.1.12+ → blocking1.8.1.13+
Whiteboard: [sg:critical] needs bug 387390 also → [sg:critical] Need 1.8 patch, needs bug 387390 also
Comment on attachment 270663 [details] [diff] [review] Fixing Ts This patch applies as-is.
Attachment #270663 - Flags: approval1.8.1.13?
Comment on attachment 270663 [details] [diff] [review] Fixing Ts approved for 1.8.1.13, a=dveditz for release-drivers
Attachment #270663 - Flags: approval1.8.1.13? → approval1.8.1.13+
Checked into the 1.8 branch.
Keywords: fixed1.8.1.13
I don't get an alert with this in Firefox 2.0.0.12 (windows) but I get the giant context menu that has shown up with these sorts of exploit test cases. In 2.0.0.13, I get no alert and a normal context menu. Was this partially fixed in 2.0.0.12 already?
Attached file (deleted) —
This works on fx2.0.0.12 (and does not work on fx2.0.0.13). The reason that the old testcase does not work is described in bug 387390 comment #9.
I tested with the new test case and repro'd the issue in 2.0.0.12. It is fixed in 2.0.0.13 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13). Marking verified. Thanks for the new testcase.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.13 → verified1.8.1.13
Comment on attachment 270663 [details] [diff] [review] Fixing Ts applies cleanly on 1.8.0
Attachment #270663 - Flags: approval1.8.0.15?
Depends on: 425232
Attachment #268657 - Attachment is private: true
Attachment #309614 - Attachment is private: true
Group: security
Depends on: 423890
It looks like this caused bug 384750, which was never addressed on branch (or linked to this bug). See the thread at http://groups.google.com/group/mozilla.dev.security/browse_frm/thread/200083a2d0cb1562#
Depends on: 390788
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: