Closed Bug 814027 (CVE-2013-0755) Opened 12 years ago Closed 12 years ago

[FIX] mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-1589)

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
13 Branch
Platform:
All
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20
Tracking Flags:
Tracking Status
firefox17 --- wontfix
firefox18 + fixed
firefox19 + fixed
firefox20 + fixed
firefox-esr10 --- unaffected
firefox-esr17 18+ fixed

People

(Reporter: curtisk, Assigned: mccr8)

Details

(Keywords: csectype-uaf, sec-critical, Whiteboard: [adv-main18+][adv-esr17+])

Attachments

(1 file, 1 obsolete file)

raw pointers are bad
945 bytes, patch
justin.lebar+bug
: review+
abillings
: sec-approval+
Details | Diff | Splinter Review
Attached file PoC (obsolete) —
-- 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 regenrecht@o2.pl Jun 2012 --> <html> <head> </head> <body onload="run();"> </body> </html> --------------- End Code Snip --------------- This PoC will trigger the vulnerability and result in EIP being set to c1c2c1c2 -- CREDIT --------------------------------------- This vulnerability was discovered by: regenrecht -- 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 zdi-disclosures@tippingpoint.com The PGP key used for all ZDI vendor communications is available from: http://www.zerodayinitiative.com/documents/zdi-pgp-key.asc -- 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: http://www.zerodayinitiative.com -- DISCLOSURE POLICY ---------------------------- Our vulnerability disclosure policy is available online at: http://www.zerodayinitiative.com/advisories/disclosure_policy/
Hmm, maybe it was jlebar, not dougt who implemented mozVibrate
Keywords: csec-uaf, sec-critical, testcase
I can't open the testcase. Is the password something else than ZDI-CAN-1589?
Alias: ZDI-CAN-1589
Summary: mozVibrate Use-After-Free Remote Code Execution Vulnerability → mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-1589)
domDoc is still a raw pointer in Navigator::Vibrate, so I'm going to assume for now that we're still affected.
Alias: ZDI-CAN-1589
status-firefox-esr10: --- → unaffected
status-firefox17: --- → affected
status-firefox18: --- → affected
status-firefox19: --- → affected
status-firefox20: --- → affected
status-firefox-esr17: --- → affected
Summary: mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-1589) → mozVibrate Use-After-Free Remote Code Execution Vulnerability
Alias: ZDI-CAN-1589
Summary: mozVibrate Use-After-Free Remote Code Execution Vulnerability → mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-1589)
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.
Assignee: nobody → continuation
Comment on attachment 684047 [details] PoC we've requested a new copy of the PoC, we can't open this one.
Attachment #684047 - Attachment is obsolete: true
Andrew, I can review your changes here, if you want to take this bug. Or I can fix it if you prefer.
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.
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 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.
Attachment #685741 - Flags: sec-approval?
Attachment #685741 - Flags: review?(justin.lebar+bug)
Attachment #685741 - Flags: review?(justin.lebar+bug) → review+
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?
Attachment #685741 - Flags: sec-approval? → sec-approval+
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.
Summary: mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-1589) → [FIX] mozVibrate Use-After-Free Remote Code Execution Vulnerability (ZDI-CAN-1589)
(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.
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. https://hg.mozilla.org/releases/mozilla-aurora/rev/7918e1e0c7b5
status-firefox17: affected → wontfix
status-firefox19: affected → fixed
https://hg.mozilla.org/mozilla-central/rev/10eeae450462
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox20: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Whiteboard: [adv-main18+][adv-esr17+]
Alias: CVE-2013-0755
Group: core-security
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: