Last Comment Bug 814027 - (CVE-2013-0755) [FIX] mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-1589)
: [FIX] mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-...
: csectype-uaf, sec-critical
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 13 Branch
: All Windows XP
-- normal (vote)
: mozilla20
Assigned To: Andrew McCreight [:mccr8]
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2012-11-21 08:41 PST by Curtis Koenig [:curtisk-use]]
Modified: 2015-10-16 11:41 PDT (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

PoC (851 bytes, application/zip)
2012-11-21 08:41 PST, Curtis Koenig [:curtisk-use]]
no flags Details
raw pointers are bad (945 bytes, patch)
2012-11-27 11:20 PST, Andrew McCreight [:mccr8]
justin.lebar+bug: review+
abillings: sec‑approval+
Details | Diff | Splinter Review

Description User image Curtis Koenig [:curtisk-use]] 2012-11-21 08:41:44 PST
Created attachment 684047 [details]

-- CVSS -----------------------------------------
7.5, AV:N/AC:L/Au:N/C:P/I:P/A:P

-- ABSTRACT -------------------------------------
TippingPoint has identified a vulnerability affecting the following products:

  Mozilla Firefox

-- VULNERABILITY DETAILS ------------------------
Version(s) Tested: Mozilla Firefox 13.0
Platform(s) Tested: Windows XP SP3

Vulnerability details 

The vulnerable function is Navigator::MozVibrate within dom/base/Navigator.cpp
From the researcher:
Note that |domDoc| is a weak pointer. As the "logic" of |JS_GetArrayLength()|
is under attacker's control, it is possible to force removal of object
currently pointed by |domDoc|. This will lead to |domDoc| becoming a dangling
pointer after the |JS_GetArrayLength()| call. Such stale pointer is then passed
to |VibrateWindowListener| constructor.

The code below triggers the vulnerability: 

Begin Code Snip 
<!doctype html>
     Mozilla Firefox 13.0
     mozVibrate dangling pointer
     Windows XP SP3 x86 code exec Jun 2012

<body onload="run();">

End Code Snip 
This PoC will trigger the vulnerability and result in EIP being set to c1c2c1c2

-- CREDIT ---------------------------------------
This vulnerability was discovered by:


-- FURTHER DETAILS ------------------------------
If supporting files were contained with this report they are provided within a password protected ZIP file. The password is the ZDI candidate number in the form: ZDI-CAN-XXXX where XXXX is the ID number.

Please confirm receipt of this report. We expect all vendors to remediate ZDI vulnerabilities within 180 days of the reported date. If you are ready to release a patch at any point leading up the the deadline please coordinate with us so that we may release our advisory detailing the issue. If the 180 day deadline is reached and no patch has been made available we will release a limited public advisory with our own mitigations so that the public can protect themselves in the absence of a patch. Please keep us updated regarding the status of this issue and feel free to contact us at any time:

Zero Day Initiative

The PGP key used for all ZDI vendor communications is available from:

-- INFORMATION ABOUT THE ZDI ---------------------
Established by TippingPoint, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities.

The ZDI is unique in how the acquired vulnerability information is used. TippingPoint does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, TippingPoint provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, TippingPoint provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product.

Please contact us for further information or refer to:

-- DISCLOSURE POLICY ----------------------------
Our vulnerability disclosure policy is available online at:
Comment 1 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2012-11-21 08:46:20 PST
Hmm, maybe it was jlebar, not dougt who implemented mozVibrate
Comment 2 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2012-11-21 09:21:25 PST
I can't open the testcase. Is the password something else than ZDI-CAN-1589?
Comment 3 User image Andrew McCreight [:mccr8] 2012-11-21 09:30:44 PST
domDoc is still a raw pointer in Navigator::Vibrate, so I'm going to assume for now that we're still affected.
Comment 4 User image Andrew McCreight [:mccr8] 2012-11-21 09:40:48 PST
This looks like it will be trivial to fix, so I can take it.

I couldn't open the PoC either.  In IRC, curtisk said that he emailed them for a new file.
Comment 5 User image Daniel Veditz [:dveditz] 2012-11-21 09:41:30 PST
Comment on attachment 684047 [details]

we've requested a new copy of the PoC, we can't open this one.
Comment 6 User image Justin Lebar (not reading bugmail) 2012-11-21 10:51:55 PST
Andrew, I can review your changes here, if you want to take this bug.  Or I can fix it if you prefer.
Comment 7 User image Andrew McCreight [:mccr8] 2012-11-27 11:20:50 PST
Created attachment 685741 [details] [diff] [review]
raw pointers are bad

I also audited other calls to GetExtantDocument that store into raw pointers, and they look okay to me (they use the pointer immediately, and then never again), though there is of course the danger of somebody later coming along and using the existing raw pointer. I still need to make sure this compiles and passes tests.
Comment 8 User image Andrew McCreight [:mccr8] 2012-11-27 11:22:27 PST
There's still no testcase to work with, but the description is good enough that I'm pretty sure this should do the trick.
Comment 9 User image Andrew McCreight [:mccr8] 2012-11-27 13:05:26 PST
Comment on attachment 685741 [details] [diff] [review]
raw pointers are bad

[Security approval request comment]
How easily can the security issue be deduced from the patch? It is quite obvious that this is probably a UAF on this field. I'm not sure how obvious it is that GetArrayLength or whatever can bring it out, but probably not that obscure.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No, well, the checkin comment describes what the patch does, so see the previous question.

Which older supported branches are affected by this flaw? 11 onwards.

If not all supported branches, which bug introduced the flaw? Bug 679966, the initial landing of MozVibrate.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Trivial patch, backporting should be trivial.

How likely is this patch to cause regressions; how much testing does it need? Seems very safe.
Comment 10 User image Al Billings [:abillings] 2012-11-27 16:37:58 PST
Comment on attachment 685741 [details] [diff] [review]
raw pointers are bad

sec-approval+ but from December 15 or later. Please check this in then and prepare branch patches.

Does this need a unit test?
Comment 11 User image Andrew McCreight [:mccr8] 2012-11-27 16:53:25 PST
A test would be nice, but I have no idea how to trigger this particular problem (as the test case is locked inside the zip file), and it isn't the sort of thing we're likely to regress.
Comment 12 User image Alex Keybl [:akeybl] 2012-12-10 06:41:33 PST
(In reply to Al Billings [:abillings] from comment #10)
> Comment on attachment 685741 [details] [diff] [review]
> raw pointers are bad
> sec-approval+ but from December 15 or later. Please check this in then and
> prepare branch patches.
> Does this need a unit test?

Correction - please land today on mozilla-central and prepare branch patches for landing tomorrow. We'd like this to make it into Firefox 18 Beta 4.
Comment 13 User image Andrew McCreight [:mccr8] 2012-12-11 09:21:14 PST
Sorry, I was on PTO yesterday. I'll go ahead and land on branches today, as this is a super low risk change. I don't think Vibrate is even enabled on desktop.

Inbound is closed, so I'm landing this on Aurora now. Assuming that passes tests, I'll land on beta and inbound later today.
Comment 15 User image Andrew McCreight [:mccr8] 2012-12-11 11:46:39 PST
Comment 16 User image Ed Morley [:emorley] 2012-12-12 02:19:44 PST

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