When user opens a page from a new tab, by either typing in the URL bar or selecting one of the pinned/bookmarked sites, then any page subsequently loaded in this tab can spawn a new window and navigate itself back to about:newtab. This is inherently unsafe, because about:newtab is chrome-privileged, and content can use the obtained reference for privilege escalation attacks.
Arbitary code execution using the COW properties exposure trick from bug 768101. Exploit for v13.0.1, open from a new tab.
Exploit for Nightly.
Attachment #637316 - Attachment mime type: text/plain → text/html
Attachment #637317 - Attachment mime type: text/plain → text/html
Given the resulting PoC I'm assigning sec-critical to this bug, but I think the critical bit is bug 768101. The about:newtab bit is more a sec-moderate waiting to turn another bug into a disaster.
Status: UNCONFIRMED → NEW
Ever confirmed: true
That exploit doesn't seem to work for me in my Mac Nightly build, FWIW. For the moment, we should probably just fix bug 724239.
(In reply to :Gavin Sharp (use firstname.lastname@example.org for email) from comment #5) > That exploit doesn't seem to work for me in my Mac Nightly build, FWIW. I've looked at the code and identified 2 possible problems: 1. The exploit opens "c:\Windows\System32\calc.exe", which is obviously not a good idea on Mac :-) 2. chromeWin's prototype may outlive the exploit window and the wrapper is GC collected, resulting in "can't access dead object" errors on repeated attempts to write properties on it. Please check the corrected version and let me know if there are any errors in the console. I've checked with Nightly 2012-06-29 and it works fine, I can only test with Windows 7 though.
Ah, yeah - I didn't look closely at the source of the PoC :) Tim: let's go with the approach in bug 724239 comment 6, and patch it in that bug. (Limi/UX are going to need to live without "back" functionality until we can make this page unprivileged.)
Assignee: nobody → ttaubert
Depends on: 724239
status-firefox-esr10: --- → unaffected
status-firefox13: --- → wontfix
status-firefox14: --- → affected
status-firefox15: --- → affected
status-firefox16: --- → affected
tracking-firefox14: --- → ?
tracking-firefox15: --- → +
tracking-firefox16: --- → +
CC'ing limi so he understands why we want to fix 724239 so badly.
The patch in bug 724239 appears to be safe and limited enough to take in Beta (Firefox 14).
tracking-firefox14: ? → +
FIXED by bug 724239.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
status-firefox14: affected → wontfix
status-firefox15: affected → fixed
status-firefox16: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
(In reply to Daniel Veditz [:dveditz] from comment #10) > The patch in bug 724239 appears to be safe and limited enough to take in > Beta (Firefox 14). It was decided in that bug that we wouldn't take it for 14.
Attachment #637906 - Attachment mime type: application/octet-stream → application/java-archive
You need to log in before you can comment on or make changes to this bug.