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

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

(In reply to comment #2) > Might be fixed by the patch for bug 311025 It isn't.

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.

Comment on attachment 198747 [details] [diff] [review] maybe wrong patch better patch coming.

This has r=brendan in person. There are more places that need to be patched to deal correctly with null principals.

I forgot to mention, I checked this in yesterday. I'll come up with a more complete patch soon.

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.

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.

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

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

Comment on attachment 198977 [details] [diff] [review] follow-on trunk cleanup patch r=mrbkap

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.

(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

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

(In reply to comment #15) > setTimeout can be used to force the same issue on 1.0.x. that is bug 311455.

Checked in on MOZILLA_1_8_BRANCH.

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.

This should be fixed on the 1.7 branches from some earlier commits I did today.

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