chrome XBL method.eval + onerror handler allows arbitary code execution

VERIFIED FIXED

Status

()

Core
Security
--
critical
VERIFIED FIXED
12 years ago
10 years ago

People

(Reporter: shutdown, Assigned: mrbkap)

Tracking

({fixed1.8, verified1.7.13})

Trunk
fixed1.8, verified1.7.13
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.13 +
blocking-aviary1.0.8 +
blocking1.8rc1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical] privilege escalation)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
You can use onerror event handler to circumvent eval()'s principal checks
and can execute arbitary code with elevated privilege. See the testcase.
(Reporter)

Comment 1

12 years ago
Created attachment 198728 [details]
testcase (1.5+ only)

Works on:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051006 Firefox/1.6a1

Firefox 1.0.x is not exploitable because onerror handler on 1.0.x
versions receive parameters different from exploitable versions.
Confirming. Might be fixed by the patch for bug 311025 -- Blake's testing
Blocks: 256195
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8rc1+
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8+
Whiteboard: [sg:high] privilege escalation
Whiteboard: [sg:high] privilege escalation → [sg:critical] privilege escalation
(In reply to comment #2)
> Might be fixed by the patch for bug 311025

It isn't.

(Assignee)

Comment 4

12 years ago
Created attachment 198747 [details] [diff] [review]
maybe wrong patch

So the basic issue here is that when we compile the outer eval, we don't have a
scripted caller, so we compile it with NULL principals. From then on, the
scripted caller of the second eval also has no principals, so any security
checks that we would do succeed trivially. This patch gives the outer eval the
principals of the |this| object, which in the case of onerror is the content
window.
Attachment #198747 - Flags: review?(brendan)
(Assignee)

Comment 5

12 years ago
Comment on attachment 198747 [details] [diff] [review]
maybe wrong patch

better patch coming.
Attachment #198747 - Attachment is obsolete: true
Attachment #198747 - Flags: review?(brendan)
(Assignee)

Comment 6

12 years ago
Created attachment 198762 [details] [diff] [review]
better, maybe incomplete, patch

This has r=brendan in person. There are more places that need to be patched to
deal correctly with null principals.
Assignee: dveditz → mrbkap
Status: NEW → ASSIGNED
Attachment #198762 - Flags: review+
(Assignee)

Comment 7

12 years ago
I forgot to mention, I checked this in yesterday. I'll come up with a more
complete patch soon.
(Assignee)

Updated

12 years ago
Blocks: 311455
(Assignee)

Comment 8

12 years ago
Created attachment 198818 [details] [diff] [review]
fix script too

If it was possible to get one's hands on a new script object, compiled without
any principals, this refuses to execute it.

Note that this is a diff -w.
Attachment #198818 - Flags: review?(brendan)
Comment on attachment 198728 [details]
testcase (1.5+ only)

Note this testcase does not work in 1.0.x as mentioned in comment 1, but we
still want this principal mishandling fixed on the 1.0 branch because there may
be other ways to force the same issue.
Attachment #198728 - Attachment description: testcase → testcase (1.5+ only)
Created attachment 198977 [details] [diff] [review]
follow-on trunk cleanup patch

This should get into the 1.8 branch along with substantive fixes, so we can
diff trunk and branch without noise.

/be
Attachment #198977 - Flags: review?(mrbkap)
Comment on attachment 198818 [details] [diff] [review]
fix script too

Yet another rigtheous fix.  We should not have tolerated null principals in a
setting (rt->findObjectPrincipals onn-null, e.g.) where principals are needed
generally, this long.

/be
Attachment #198818 - Flags: review?(brendan)
Attachment #198818 - Flags: review+
Attachment #198818 - Flags: approval1.8rc1?
(Assignee)

Comment 12

12 years ago
Comment on attachment 198977 [details] [diff] [review]
follow-on trunk cleanup patch

r=mrbkap
Attachment #198977 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 13

12 years ago
I checked in the additional patch. Marking this bug as FIXED.

Brendan, I wasn't sure if you wanted me to check your cleanup patch (attachment
198977 [details] [diff] [review]) in, so I left it alone.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(In reply to comment #13)
> I checked in the additional patch. Marking this bug as FIXED.
> 
> Brendan, I wasn't sure if you wanted me to check your cleanup patch (attachment
> 198977 [edit]) in, so I left it alone.

I checked that into the trunk yesterday.  Just want to emphasize that we should
sync trunk and 1.8 branch when this goes in for rc1.

/be

Updated

12 years ago
Attachment #198818 - Flags: approval1.8rc1? → approval1.8rc1+
(Assignee)

Updated

12 years ago
Depends on: 311952

Comment 15

12 years ago
(In reply to comment #9)
> Note this testcase does not work in 1.0.x as mentioned in comment 1, but we
> still want this principal mishandling fixed on the 1.0 branch because there may
> be other ways to force the same issue.

setTimeout can be used to force the same issue on 1.0.x.

setTimeout(eval, 0, code, obj);
When eval is called from timeout, scripted caller is null.

Comment 16

12 years ago
Created attachment 199419 [details]
exploit testcase that works on 1.0.7 and suite 1.7.12
(Reporter)

Comment 17

12 years ago
(In reply to comment #15)
> setTimeout can be used to force the same issue on 1.0.x.

that is bug 311455.
(Assignee)

Comment 18

12 years ago
Checked in on MOZILLA_1_8_BRANCH.
Keywords: fixed1.8

Updated

12 years ago
Flags: testcase+
Attachment #198762 - Flags: approval1.7.13+
Attachment #198762 - Flags: approval-aviary1.0.8+
Comment on attachment 198818 [details] [diff] [review]
fix script too

aviary101/moz17 landing approval: a=dveditz for drivers. Please add the fixed1.7.13 and fixed-aviary1.0.8 keywords when landed.
Attachment #198818 - Flags: approval1.7.13+
Attachment #198818 - Flags: approval-aviary1.0.8+
Attachment #198977 - Flags: approval1.7.13+
Attachment #198977 - Flags: approval-aviary1.0.8+
(Assignee)

Comment 20

11 years ago
This should be fixed on the 1.7 branches from some earlier commits I did today.
Keywords: fixed-aviary1.0.8, fixed1.7.13

Updated

11 years ago
Status: RESOLVED → VERIFIED
Keywords: fixed-aviary1.0.8, fixed1.7.13 → verified-aviary1.0.8, verified1.7.13
verified with:
Windows:
Moz - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060215
Fx - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060215
Firefox/1.0.8
Macintosh:
Moz - Mozilla/5.0 (Macintosh; U;PPC Mac OS X Mach-O; en-US; rv:1.7.13)
Gecko/20060215 Firefox/1.0.8
Fx - Mozilla/5.0 (Macintosh; U;PPC Mac OS X Mach-O; en-US; rv:1.7.13)
Gecko/20060215 Firefox/1.0.8
Linux
Moz - Mozilla/5.0 (X11; U;Linux i686; en-US; rv:1.7.13) Gecko/20060215
Group: security

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.