Bug 760996 (CVE-2012-3970)

Heap-use-after-free in nsTArray_base<nsTArrayDefaultAllocator>::Length()

VERIFIED FIXED

Status

()

Core
SVG
VERIFIED FIXED
5 years ago
6 months ago

People

(Reporter: Arthur Gerkis, Assigned: dholbert)

Tracking

(Blocks: 1 bug, 5 keywords)

Trunk
x86_64
Linux
crash, csectype-uaf, regression, sec-critical, testcase
Points:
---
Dependency tree / graph
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox15+ fixed, firefox16+ verified, firefox-esr10 unaffected)

Details

(Whiteboard: [advisory-tracking+][asan] fixed by bug 761507)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 629613 [details]
test-case triggering the crash (*.zip)

ASan detected use-after-free when running attached test-case. ASan log is for build http://hg.mozilla.org/mozilla-central/rev/12ab69851e05

When testing, was not able to reproduce on Windows 7 x64 - nor stable, neither 15.0a1. Crashes for me only on Linux (Ubuntu 11.10 x64)
(Reporter)

Comment 1

5 years ago
Created attachment 629614 [details]
ASan log (12ab69851e05)
Component: Untriaged → SVG
Product: Firefox → Core
QA Contact: untriaged → general
Is DOMSVGTests.cpp only a test file, or is that present in release builds? Is the problem _in_ the SVG file or is it a bug in the underlying nsTArray?

Daniel: can you find an owner for this one? Thanks!
Assignee: nobody → dholbert
(In reply to Daniel Veditz [:dveditz] from comment #2)
> Is DOMSVGTests.cpp only a test file, or is that present in release builds?

Present in release builds. It lets authors render different content depending on available features & the system language.

> Is the problem _in_ the SVG file or is it a bug in the underlying nsTArray?

It's almost certainly a SVG bug.

> Daniel: can you find an owner for this one? Thanks!

CC'ing longsonr, since he wrote that file and has been working with that code recently.

In fact -- I'd bet that this is fixed by his patch on bug 761507.  (That patch lets us keep DOMSVGTests' PropertyTable entries around after adoptNode is called, and this bug's ASAN log is in nsDocument::AdoptNode() calling nsPropertyTable::PropertyList::DeletePropertyFor, so I doubt we'll hit the ASAN-flagged stack anymore.)

That patch has landed on mozilla-inbound, but it hasn't quite made it to mozilla-central yet. Once it does, it'd be awesome if Arthur or someone with ASAN configuration could re-test to verify that this is fixed.
Whiteboard: [dupe of bug 761507?]
bug 761507's patch has now made it to mozilla-central (bug 761507 comment 9).

:decoder tells me he's making automated Linux 64-bit ASAN builds now, so I tried the one from yesterday and the one from today -- those are, in order:
http://people.mozilla.org/~choller/firefox/asan/20120606-mozilla-central-debug-a6c39a15557b+asan.html
http://people.mozilla.org/~choller/firefox/asan/20120607-mozilla-central-debug-7e4c2abb9fc9+asan.html

Using the testcase attached here, yesterday's build crashes and reports a use-after-free.  Today's build is fine -- no crash, no use-after-free. So, confirmed fixed by bug 761507. Pretty sure this is a duplicate of that bug -- marking as such.

Thanks for the bug report, Arthur!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Whiteboard: [dupe of bug 761507?]
Version: 15 Branch → Trunk
Duplicate of bug: 761507
...though note that, for security-bug-bounty purposes, this bug here was filed before bug 761507 (as well as before related bug 761499).
Daniel: if you don't mind I'd like to call this one "FIXED" rather than "DUPE" as a testing hint that we should verify this testcase separately to be sure. I'm going to save Al some work by marking this verified based on comment 4, but we should double-check when this lands on Aurora (to make Firefox 15).
Status: RESOLVED → VERIFIED
status-firefox-esr10: --- → unaffected
status-firefox15: --- → affected
status-firefox16: --- → verified
tracking-firefox15: --- → +
tracking-firefox16: --- → +
Keywords: crash, sec-critical, testcase
Resolution: DUPLICATE → FIXED
Whiteboard: fixed by bug 761507
Depends on: 761507
Blocks: 754592
Keywords: regression

Comment 8

5 years ago
(In reply to Daniel Holbert [:dholbert] from comment #5)
> ...though note that, for security-bug-bounty purposes, this bug here was
> filed before bug 761507 (as well as before related bug 761499).

According to http://www.mozilla.org/security/bug-bounty.html the bug must be in a Beta or release candidate. Unless we fail to fix it in Aurora, that won't be the case will it?
(In reply to Robert Longson from comment #8)
> According to http://www.mozilla.org/security/bug-bounty.html the bug must be
> in a Beta or release candidate. Unless we fail to fix it in Aurora, that
> won't be the case will it?

I don't think the document is right there, or at least the formulation is misleading. Even nightly is eligible for bug bounty and has always been since I learned about the program.

Comment 10

5 years ago
Someone should update the document to match reality then.
(In reply to Robert Longson from comment #10)
> Someone should update the document to match reality then.

The FAQ has always said
http://www.mozilla.org/security/bug-bounty-faq.html#development-releases
Fixed by bug 761507, fixed in 15.
status-firefox15: affected → fixed
Whiteboard: fixed by bug 761507 → [advisory-tracking+] fixed by bug 761507
Alias: CVE-2012-3970
Group: core-security
Whiteboard: [advisory-tracking+] fixed by bug 761507 → [advisory-tracking+][asan] fixed by bug 761507
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+
Keywords: csectype-uaf
You need to log in before you can comment on or make changes to this bug.