Bug 738985 (CVE-2012-0469)

heap-use-after-free at mozilla::dom::indexedDB::IDBKeyRange::cycleCollection::Trace

VERIFIED FIXED in Firefox 12

Status

()

Core
DOM: IndexedDB
--
critical
VERIFIED FIXED
5 years ago
2 months ago

People

(Reporter: Aki Helin, Assigned: khuey)

Tracking

({csectype-uaf, regression})

Trunk
mozilla14
csectype-uaf, regression
Points:
---
Bug Flags:
sec-bounty +
in-testsuite ?

Firefox Tracking Flags

(firefox11 wontfix, firefox12+ verified, firefox13+ verified, firefox14 verified, firefox-esr1012+ verified)

Details

(Whiteboard: [sg:critical][qa+:ashughes][asan])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
Created attachment 609037 [details]
file to trigger the issue

ASan reports a heap-use-after-free error when the attached page is opened. The file was minimized against 14.0a1 (2012-03-24) and doesn't seem to reproduce anymore on 12.0, but similar files caused also it to crash during minimization. The trace was https://crash-stats.mozilla.com/report/index/bp-e750dc35-be93-426f-aff3-cd82b2120324

To reproduce, open idb.html in an ASan build and wait about 7 seconds.
(Reporter)

Comment 1

5 years ago
Created attachment 609038 [details]
asan trace
(Reporter)

Comment 2

5 years ago
This one seems to usually crash Firefox 12.0 when closing the tab:
  <script>
  for (var foo = 0; foo < 1000; foo++) {
     var x = new Array(1000);
     IDBKeyRange.only(1);
     IDBKeyRange.only("'a'").lower;
  }
  </script>

Crash report: https://crash-stats.mozilla.com/report/index/bp-8684865e-5e04-46ed-997a-f0bdf2120324
Component: General → DOM: IndexedDB
Product: Firefox → Core
QA Contact: general → indexeddb
I can reproduce this on trunk on Windows.
Assignee: nobody → khuey
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Version: 12 Branch → Trunk
Created attachment 609053 [details] [diff] [review]
Patch

IDBKeyRange assumes that it will be unlinked before it is destroyed, but that assumption is wrong, because it is not wrapper cached.  In Aki's testcase the dead IDBKeyRange remains in the XPConnect hashtable because it never called NS_DROP_JS_OBJECTS.

This is a regression from Bug 692669.
Attachment #609053 - Flags: review?(bent.mozilla)
status-firefox-esr10: --- → affected
status-firefox11: --- → wontfix
status-firefox12: --- → affected
status-firefox13: --- → affected
status-firefox14: --- → affected
tracking-firefox-esr10: --- → ?
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
Keywords: regression
Whiteboard: [sg:critical]
Thanks for the bug report and testcase Aki!
(Reporter)

Comment 6

5 years ago
Patch looks good here. Neither the attached cases nor the originals cause any issues after applying it.

5h from bug to patch during weekend. Not bad :)
Duplicate of this bug: 739054

Updated

5 years ago
tracking-firefox12: ? → +
tracking-firefox13: ? → +
Comment on attachment 609053 [details] [diff] [review]
Patch

Review of attachment 609053 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with this change:

::: dom/indexedDB/IDBKeyRange.cpp
@@ +351,5 @@
> +IDBKeyRange::~IDBKeyRange()
> +{
> +  if (mRooted) {
> +    NS_DROP_JS_OBJECTS(this, IDBKeyRange);
> +    mCachedLowerVal = JSVAL_VOID;

No need to do anything else after dropping. You're in the destructor.
Attachment #609053 - Flags: review?(bent.mozilla) → review+
I'm a little worried that it is easy to figure out the bug from the fix, so I snuck this one into the tree in a merge changeset.

https://hg.mozilla.org/mozilla-central/rev/c3fd0768d46a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox14: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Comment on attachment 609053 [details] [diff] [review]
Patch

We'll want this everywhere.

[Approval Request Comment]
Regression caused by (bug #): bug 692669
User impact if declined: sg:crit
Testing completed (on m-c, etc.): It is on m-c
Risk to taking this patch (and alternatives if risky): Very low
String changes made by this patch: N/A
Attachment #609053 - Flags: approval-mozilla-esr10?
Attachment #609053 - Flags: approval-mozilla-beta?
Attachment #609053 - Flags: approval-mozilla-aurora?
We should land this on branches all at once near the end of the Firefox 12 cycle. Code freeze is April 13 (I think) so sometime in the day or two before that.
Blocks: 692669
tracking-firefox-esr10: ? → 12+
Holding on approval to give this fix some time to bake on m-c.

(In reply to Daniel Veditz [:dveditz] from comment #11)
> We should land this on branches all at once near the end of the Firefox 12
> cycle. Code freeze is April 13 (I think) so sometime in the day or two
> before that.

April 13th is the code freeze. Is this a change in process you'd like to make or is this bug particularly nasty?
Comment on attachment 609053 [details] [diff] [review]
Patch

[Triage Comment]
Approving for landing on all branches.
Attachment #609053 - Flags: approval-mozilla-esr10?
Attachment #609053 - Flags: approval-mozilla-esr10+
Attachment #609053 - Flags: approval-mozilla-beta?
Attachment #609053 - Flags: approval-mozilla-beta+
Attachment #609053 - Flags: approval-mozilla-aurora?
Attachment #609053 - Flags: approval-mozilla-aurora+
Did we decide when to land this?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #14)
> Did we decide when to land this?

Before beta 5's go-to-build please (4/10).
https://hg.mozilla.org/releases/mozilla-aurora/rev/008838e028ba
https://hg.mozilla.org/releases/mozilla-beta/rev/426df312cfa3
https://hg.mozilla.org/releases/mozilla-esr10/rev/c61ea8a2402c
status-firefox-esr10: affected → fixed
status-firefox12: affected → fixed
status-firefox13: affected → fixed
Whiteboard: [sg:critical] → [sg:critical][qa+]
How does one get an ASan build for "releases" (10.0.4ESR, 12 Beta, etc)?
You don't need an ASAN build, just load the testcase in the browser and refresh it a few times.
Alias: CVE-2012-0469
Verified in nightly (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120417 Firefox/14.0a1) using attached testcase per comment 18. Crashes in Firefox 11 on same machine.
Status: RESOLVED → VERIFIED
Verified fixed in Firefox ESR 10.0.4pre 2012-04-18.
status-firefox-esr10: fixed → verified
Duplicate of this bug: 745679

Updated

5 years ago
status-firefox12: fixed → verified
Group: core-security
Flags: in-testsuite?
Verified fixed in Firefox 13.0b4 and Firefox 14.0a2 2012-05-22.
status-firefox13: fixed → verified
status-firefox14: fixed → verified
Whiteboard: [sg:critical][qa+] → [sg:critical][qa+:ashughes]
http://www.vupen.com/blog/20120625.Advanced_Exploitation_of_Mozilla_Firefox_UaF_CVE-2012-0469.php
Whiteboard: [sg:critical][qa+:ashughes] → [sg:critical][qa+:ashughes][asan]
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+

Comment 26

a year ago
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #24)
> http://www.vupen.com/blog/20120625.
> Advanced_Exploitation_of_Mozilla_Firefox_UaF_CVE-2012-0469.php

Hi, thanks for your post, but I couldn't connnect to the website(I have no idea about why, it just doesn't work even if I use a proxy). Could you please post an offline version of your php page or any other reference? I would like to get some more details about this bug so as to study it.

Thanks a lot.
(In reply to tgn from comment #26)
> Hi, thanks for your post, but I couldn't connnect to the website(I have no
> idea about why, it just doesn't work even if I use a proxy).

Kyle was linking to a blog post by Vupen. He did not write that post himself. According to Wikipedia, Vupen shut down in 2015, so I guess their blog post was taken down. Maybe you could find the post in some web archive site.
Keywords: csectype-uaf
You need to log in before you can comment on or make changes to this bug.