Comment 1 shutdown 2006-02-14 03:29:58 PST

Created attachment 211841 [details]
exploit testcase

exploitable:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060213 Firefox/1.5
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060213 Firefox/1.6a1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.13) Gecko/20060213 Firefox/1.0.8

Comment 2 Daniel Veditz [:dveditz] 2006-02-14 13:20:14 PST

Another missing context push/pop.

Comment 3 Boris Zbarsky [:bz] (TPAC) 2006-02-14 13:25:45 PST

So what happens here?  This is opening a modal window, so I'd expect it to do the right thing....

Comment 4 Boris Zbarsky [:bz] (TPAC) 2006-02-14 13:44:11 PST

Note that I can't debug this in a useful way due to bug 326501.  Is there a non-tree-related testcase possible?

Comment 5 Daniel Veditz [:dveditz] 2006-02-14 14:24:43 PST

(In reply to comment #4)
> Is there a non-tree-related testcase possible?

mrbkap and I have a fix in mind for this.

Comment 6 Daniel Veditz [:dveditz] 2006-02-15 17:17:45 PST

Created attachment 212066 [details] [diff] [review]
push the js context

This resolves the permissions issue by making sure the right context will be found on the stack.

Comment 7 Blake Kaplan (:mrbkap) 2006-02-15 17:47:36 PST

Comment on attachment 212066 [details] [diff] [review]
push the js context

>Index: security/manager/ssl/src/nsCrypto.cpp
>@@ -1773,15 +1774,22 @@ nsCryptoRunnable::Run()
>+  if (!stack || NS_FAILED(stack->Push(cx)))
>+    return NS_ERROR_FAILURE;

Nit: Please overbrace this if statement (even though it isn't necessary).

While it'd be nice to have an auto-pusher/popper to guard against early returns, that's another bug for another day. r=mrbkap

Comment 8 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2006-02-15 19:47:13 PST

Comment on attachment 212066 [details] [diff] [review]
push the js context

sr=dbaron (trusting mrbkap's review)

Is the bug on a class to do this filed?

Comment 9 Daniel Veditz [:dveditz] 2006-02-15 21:39:29 PST

Comment on attachment 212066 [details] [diff] [review]
push the js context

approved for 1.7/1.8.0/aviary101 branches, a=dveditz

Comment 10 Daniel Veditz [:dveditz] 2006-02-15 21:49:54 PST

Patch checked in to trunk and aviary101, moz17, moz180, and moz18 branches

Comment 11 Tracy Walker [:tracy] 2006-02-16 14:10:08 PST

Verified on:
Windows:
Fx: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060216 Firefox/1.0.8
Moz: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060216
Mac:
Fx: Mozilla/5.0 (Macintosh; U;PPC Mac OS X Mach-O; en-US; rv:1.7.13)
Gecko/20060216 Firefox/1.0.8
Moz: Not available for 0216
Linux:
Fx: Not available for 0216
Moz: Mozilla/5.0 (X11; U;Linux i686; en-US; rv:1.7.13) Gecko/20060216

Comment 12 Bob Clary [:bc:] 2006-02-22 00:52:30 PST

ff 1.0.8/mac/20060221 opens the Software Security Device Change password dialog. Doesn't seem nice.

Comment 13 Bob Clary [:bc:] 2006-02-23 04:13:30 PST

I crash with Firefox 1.0.8 linux 20060221 on the windowsPoC after closing the
security device password dialog. I don't know if this is the exploitable crash though.

Comment 14 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-02-23 04:16:56 PST

Well, generateCRMFRequest crashes easily when using wrong arguments, see bug 327524. Not sure, though, if that's the issue in comment 13.

Comment 15 Jay Patel [:jay] 2006-02-24 13:48:36 PST

v.fixed on 1.8.0 branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060224 Firefox/1.5.0.1, testcase exploit blocked, js console:

Attempt to load a javascript: URL from one host
in a window displaying content from another host
was blocked by the security manager.

Comment 16 Bob Clary [:bc:] 2006-02-24 14:29:05 PST

I have the crash in ff 1.0.8/linux in gdb.

0x0116918a in ns_if_addref<nsIRegion*> (expr=0x78)
   at ../../../dist/include/xpcom/nsISupportsUtils.h:114
114        return expr ? expr->AddRef() : 0;

Comment 17 Frederic Crozat 2006-04-24 10:51:17 PDT

I've backported patch from bug #330900 on firefox 1.0.8 build and despite fixing crash with testcase from bug #327524, I still get crash with exploit testcase for this bug.

Comment 18 Alfred Peng 2006-06-13 00:19:44 PDT

I ran the testcase on the released Mozilla1.7.13 on Solaris10 and Fedora5. It still crashes. On Fedora, you need to reload the testcase to reproduce that issue.

Comment 19 Daniel Veditz [:dveditz] 2006-06-13 10:44:21 PDT

(In reply to comment #18)
> I ran the testcase on the released Mozilla1.7.13 on Solaris10 and Fedora5. It
> still crashes. On Fedora, you need to reload the testcase to reproduce that
> issue.

Where does it crash? In addition to the bug 330900 crash in generateCRMFrequest itself this bug also depends on bug 326501 which describes a crash in tree views.

Note that *this* bug was never about a crash, it was about running the callback javascript code with chrome privileges. If neither 330900 nor 326501 describes the crash you're seeing now we need a new bug.

Comment 20 Alfred Peng 2006-06-15 00:34:55 PDT

Created attachment 225681 [details]
Core stack

The core stack for Mozilla1.7.13 on Solaris 10: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060615.

Comment 21 Alfred Peng 2006-06-15 00:39:50 PDT

Created attachment 225682 [details]
Core stack on ubuntu

The core stack for Mozilla1.7.13 on Ubuntu: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060615.

Comment 22 chris hofmann 2006-07-12 10:58:52 PDT

shutdown,  can you contact me at chofmann@mozilla.org?  Having a problem getting mail though to you.  thanks.

Comment 23 Alfred Peng 2006-07-13 21:12:38 PDT

With the patch for bug 326501 applied, no crash anymore.

Comment 24 Bob Clary [:bc:] 2006-08-22 13:02:09 PDT

https://bugzilla.mozilla.org/attachment.cgi?id=211841
ff2b2 windows/linux verified fixed 1.8
Error: uncaught exception: [Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: "chrome://global/content/bindings/tree.xml Line: 0"]