Last Comment Bug 863933 - (CVE-2013-1687) Arbitrary code execution via XBL
(CVE-2013-1687)
: Arbitrary code execution via XBL
Status: VERIFIED FIXED
[adv-main22+]
: regression, sec-critical
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: All All
: -- critical (vote)
: ---
Assigned To: Bobby Holley (:bholley) (busy with Stylo)
: Matt Wobensmith [:mwobensmith][:matt:]
: Andrew Overholt [:overholt]
Mentors:
Depends on: 829872 865947 CVE-2013-1703 866823
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-19 17:10 PDT by Mariusz Mlynski
Modified: 2014-09-17 07:49 PDT (History)
12 users (show)
dveditz: sec‑bounty+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
unaffected
-
verified
-
verified
unaffected
unaffected


Attachments
Exploit (launches calc.exe on windows) (1.44 KB, text/html)
2013-04-19 17:11 PDT, Mariusz Mlynski
no flags Details

Description Mariusz Mlynski 2013-04-19 17:10:45 PDT
It is possible to compile a user-defined function in the XBL scope of a "marquee" element -- using |_setEventListener| method. Once the defined event is triggered, the code running in the XBL scope can access all content protected by System Only Wrapper. It can also open arbitrary chrome-privileged pages.

Additionally, remote web content can access privileged methods from property descriptor objects on Chrome Object Wrappers fetched off of an XBL scope. They can be subsequently used to perform a cross-site scripting attack on a frame with a privileged page, which allows drive-by download of malware.
Comment 1 Mariusz Mlynski 2013-04-19 17:11:39 PDT
Created attachment 739893 [details]
Exploit (launches calc.exe on windows)

This opens C:\Windows\System32\calc.exe on Windows or alerts Components.classes on other systems. Works in Firefox 22-23, earlier versions may work partially or not at all.
Comment 2 Mariusz Mlynski 2013-04-19 17:24:34 PDT
Comment on attachment 739893 [details]
Exploit (launches calc.exe on windows)

Oh, btw, run from HTTP to avoid the mixed-content blocker ruining things.
Comment 3 David Bolter [:davidb] 2013-04-25 13:15:45 PDT
Matt agreed to confirm exploitability (or not) of branches. \o/
Comment 4 Andrew McCreight [:mccr8] 2013-04-25 13:16:22 PDT
Is this something that may affect all branches, or might it be a regression from more recent patches?
Comment 5 Bobby Holley (:bholley) (busy with Stylo) 2013-04-25 18:45:03 PDT
Holy moly Mariusz, this is probably the best Mozilla exploit I've ever seen. The depth and cleverness here are off the charts. There are at least three distinct security exploits working in tandem here, and a number of other bits of suboptimal Gecko behavior being used as well. You have my deepest respect.

For those following along, here's the short version of what this testcase does:
1 - Hijacks the XBL scope using <marquee>
2 - Using the nsExpandedPrincipal associatd with the XBL scope, exploits a bug in CAPS to load "about:" in an iframe, which ends up loading with system principal.
3 - Using the ability of XBL scopes to create Xray waivers to content, bypasses COWs to access the |about:| iframe's Object.prototype, grabs __lookupSetter__, uses __lookupSetter__ to get a chrome-side setter to Element.innerHTML, and invokes the setter with the payload, causing it to get loaded as chrome.

Bugs 1 and 2 are really bad bugs but straightforward to fix. The XBL Scope hijack is particularly problematic on Beta, because we still have the Sandbox exception for __exposedProps__ there, meaning that this allows arbitrary COW bypasses even without the cleverness of (2) and (3). Thankfully, those bugs should be easy to backport.

I'm going to file dependent bugs for all of the pieces here.
Comment 6 Bobby Holley (:bholley) (busy with Stylo) 2013-04-29 10:17:42 PDT
I still need to file the lynchpin bug here - I'll get to it shortly.
Comment 7 Matt Wobensmith [:mwobensmith][:matt:] 2013-04-29 15:09:20 PDT
Exploit works on 22/23, all Windows.

For the purposes of this bug, I set the branch flags. However, I understand that components of this bug - the bugs that were filed as a result - may actually affect older branches.
Comment 8 Matt Wobensmith [:mwobensmith][:matt:] 2013-04-29 15:13:28 PDT
As above, can we assume this affects Mac/Linux as well?
Comment 9 Andrew McCreight [:mccr8] 2013-04-29 15:57:10 PDT
yeah.
Comment 12 Alex Keybl [:akeybl] 2013-05-24 09:47:29 PDT
Spoke with Bobby over email, no need to track this meta bug specifically (we're tracking/uplifting related bugs).
Comment 13 Andrew McCreight [:mccr8] 2013-05-28 11:34:45 PDT
I think this can be closed, as all of the blocking bugs have been marked fixed.  This should probably also be verified as fixed.
Comment 14 Matt Wobensmith [:mwobensmith][:matt:] 2013-05-30 14:20:12 PDT
I will verify this.
Comment 15 Matt Wobensmith [:mwobensmith][:matt:] 2013-05-31 15:38:36 PDT
Confirmed exploit on FF23, 2013-04-19
Verified fixed on FF22, 2013-05-31
Verified fixed on FF23, 2013-05-31
Verified fixed on FF24, 2013-05-31
Comment 16 Cody Crews 2014-09-05 10:04:38 PDT
Is there any way that I could get access to the attachment testcase?  I've been studying older exploits some this week, and I would love to see this work.
Comment 17 Bobby Holley (:bholley) (busy with Stylo) 2014-09-05 15:26:10 PDT
(In reply to codyc from comment #16)
> Is there any way that I could get access to the attachment testcase?  I've
> been studying older exploits some this week, and I would love to see this
> work.

I have emailed the testcase to cody.
Comment 18 Al Billings [:abillings] 2014-09-05 19:55:31 PDT
(In reply to Bobby Holley (:bholley) from comment #17)

> I have emailed the testcase to cody.

Heh. I encrypted it with his new key and did the same...
Comment 19 Cody Crews 2014-09-16 14:46:51 PDT
Aww, now I don't feel all super special ;-)

Note You need to log in before you can comment on or make changes to this bug.