1.76 KB, patch
|Details | Diff | Splinter Review|
4.48 KB, text/plain
5.26 KB, text/plain
crypto.generateCRMFRequest() has a vulnerability similar to bug 314865.
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
Another missing context push/pop.
So what happens here? This is opening a modal window, so I'd expect it to do the right thing....
Note that I can't debug this in a useful way due to bug 326501. Is there a non-tree-related testcase possible?
Depends on: 326501
(In reply to comment #4) > Is there a non-tree-related testcase possible? mrbkap and I have a fix in mind for this.
This resolves the permissions issue by making sure the right context will be found on the stack.
Attachment #212066 - Flags: approval-branch-1.8.1? → approval-branch-1.8.1?(kengert)
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
Attachment #212066 - Flags: review?(mrbkap) → review+
Attachment #212066 - Flags: approval-branch-1.8.1?(kengert) → approval-branch-1.8.1+
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?
Attachment #212066 - Flags: superreview?(jst) → superreview+
Comment on attachment 212066 [details] [diff] [review] push the js context approved for 1.7/1.8.0/aviary101 branches, a=dveditz
Patch checked in to trunk and aviary101, moz17, moz180, and moz18 branches
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
ff 1.0.8/mac/20060221 opens the Software Security Device Change password dialog. Doesn't seem nice.
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.
Well, generateCRMFRequest crashes easily when using wrong arguments, see bug 327524. Not sure, though, if that's the issue in comment 13.
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;
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.
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.
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.
The core stack for Mozilla1.7.13 on Ubuntu: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060615.
shutdown, can you contact me at firstname.lastname@example.org? Having a problem getting mail though to you. thanks.
With the patch for bug 326501 applied, no crash anymore.
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"]
You need to log in before you can comment on or make changes to this bug.