Closed Bug 769108 (CVE-2012-3965) Opened 8 years ago Closed 8 years ago

Chrome-privileged about:newtab remains in the history chain

Categories

(Core :: DOM: Navigation, defect)

13 Branch
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla16
Tracking Status
firefox13 --- wontfix
firefox14 + wontfix
firefox15 + fixed
firefox16 + fixed
firefox-esr10 --- unaffected

People

(Reporter: marius.mlynski, Assigned: ttaubert)

References

Details

(Keywords: sec-critical, Whiteboard: [advisory-tracking+])

Attachments

(2 files, 1 obsolete file)

772 bytes, text/html
Details
622 bytes, application/java-archive
Details
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.
Attached file PoC for v13.0.1
Arbitary code execution using the COW properties exposure trick from bug 768101. Exploit for v13.0.1, open from a new tab.
Attached file PoC for v16.0a1 (obsolete) —
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
Keywords: sec-critical
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 gavin@gavinsharp.com 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.
Attached file PoC v2 for v16.0a1
Attachment #637317 - Attachment is obsolete: true
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
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).
FIXED by bug 724239.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: in-testsuite+
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.
Whiteboard: [advisory-tracking+]
Alias: CVE-2012-3965
Attachment #637906 - Attachment mime type: application/octet-stream → application/java-archive
Group: core-security
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.