Bug 916685 (CVE-2013-5601)

ASAN use-after free in GC allocation in nsEventListenerManager::SetEventHandler

RESOLVED FIXED in Firefox 25, Firefox OS v1.2

Status

()

Core
DOM: Events
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: Nils, Assigned: smaug)

Tracking

({csectype-uaf, regression, sec-critical})

Trunk
mozilla27
x86_64
Linux
csectype-uaf, regression, sec-critical
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox24 wontfix, firefox25+ fixed, firefox26+ fixed, firefox27+ verified, firefox-esr17 unaffected, firefox-esr2425+ fixed, b2g18 unaffected, b2g-v1.1hd unaffected, b2g-v1.2 fixed)

Details

(Whiteboard: [asan][adv-main25+][adv-esr24-1+])

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 805180 [details]
crash.html

The attached testcase crashes the nightly ASAN build.  It require domFuzzLite3. ASAN output attached in stack.txt.
(Reporter)

Comment 1

4 years ago
Created attachment 805181 [details]
stack.txt (ASAN output)
Sounds bad.
Keywords: sec-critical
Keywords: csec-uaf
Whiteboard: [asan]
I'll take a look at this this week.
Assignee: nobody → continuation
(Assignee)

Updated

4 years ago
Attachment #805180 - Attachment mime type: text/plain → text/html
(Assignee)

Comment 4

4 years ago
Created attachment 810312 [details] [diff] [review]
patch

Bring back the pre-EventHandler behavior
Assignee: continuation → bugs
Attachment #810312 - Flags: review?(bzbarsky)
(Assignee)

Comment 5

4 years ago
http://mxr.mozilla.org/comm-esr17/source/mozilla/content/events/src/nsEventListenerManager.cpp?rev=618ffd249ae7&mark=778-780#777 has the old behavior.
Comment on attachment 810312 [details] [diff] [review]
patch

r=me, but how are we getting a null boundHandler here?  Is the JSObjectFromInterface failing?  Seems like the only way that could happen...
Attachment #810312 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 7

4 years ago
We end up to BindCompiledEventHandler when mIsInitialized is false. nsJSContext hasn't been
unlinked yet, so we're dealing with a context which initialization somehow failed.
(Assignee)

Comment 8

4 years ago
Comment on attachment 810312 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): I think Bug 807226
User impact if declined: crashes, possibly exploitable
Testing completed (on m-c, etc.):  NA
Risk to taking this patch (and alternatives if risky): Should be safe. Setting a member variable explicitly to null 
String or IDL/UUID changes made by this patch: NA
Attachment #810312 - Flags: sec-approval?
Attachment #810312 - Flags: approval-mozilla-esr24?
Attachment #810312 - Flags: approval-mozilla-beta?
Attachment #810312 - Flags: approval-mozilla-aurora?
status-b2g18: --- → ?
status-firefox24: --- → wontfix
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox-esr17: --- → unaffected
status-firefox-esr24: --- → affected
tracking-firefox27: --- → +
Comment on attachment 810312 [details] [diff] [review]
patch

sec-approval+ for trunk. As you say, this looks pretty safe so I'm giving it branch approval elsewhere for after it makes it into trunk and things are green.

Is B2G affected?
Attachment #810312 - Flags: sec-approval?
Attachment #810312 - Flags: sec-approval+
Attachment #810312 - Flags: approval-mozilla-esr24?
Attachment #810312 - Flags: approval-mozilla-esr24+
Attachment #810312 - Flags: approval-mozilla-beta?
Attachment #810312 - Flags: approval-mozilla-beta+
Attachment #810312 - Flags: approval-mozilla-aurora?
Attachment #810312 - Flags: approval-mozilla-aurora+
tracking-firefox25: --- → +
tracking-firefox26: --- → +
tracking-firefox-esr24: --- → +
(Assignee)

Comment 10

4 years ago
I have no idea which branch b2g uses these days, so I don't know whether it is affected.
b2g-18 shouldn't be.
(Assignee)

Comment 11

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/802e8457aef7
status-b2g18: ? → unaffected
status-b2g-v1.2: --- → affected
https://hg.mozilla.org/mozilla-central/rev/802e8457aef7
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox27: affected → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
https://hg.mozilla.org/releases/mozilla-aurora/rev/a684bd944d90
https://hg.mozilla.org/releases/mozilla-beta/rev/e57b395d27d3
https://hg.mozilla.org/releases/mozilla-esr24/rev/79e83c7512d5
status-b2g-v1.1hd: --- → unaffected
status-b2g-v1.2: affected → fixed
status-firefox25: affected → fixed
status-firefox26: affected → fixed
status-firefox-esr24: affected → fixed
Hi Nils - I'm not able to recreate the crash with an ASan build from 2013-09-16 and the domFuzz extension.

Would you mind trying this on a recent build to verify that we've indeed fixed it? Any branch. Thank you.
(Reporter)

Comment 15

4 years ago
Hi Matt, I can confirm that this testcase doesn't crash anymore in the latest ASAN build. I will keep a look out for similar crashes in my next fuzzing run.
Thank you, Nils.
status-firefox27: fixed → verified
Whiteboard: [asan] → [asan][adv-main25+][adv-esr24-1+]
Alias: CVE-2013-5601
Blocks: 807226
tracking-firefox-esr24: + → 25+
Keywords: regression
Group: core-security
You need to log in before you can comment on or make changes to this bug.