Bug 719612 (CVE-2012-0444)

Mozilla Firefox Ogg Vorbis Decoding Memory Corruption (ZDI-CAN-1477)

VERIFIED FIXED in Firefox 10

Status

()

Core
Audio/Video
VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: abillings, Assigned: derf)

Tracking

({crash, testcase, verified1.9.2})

Trunk
mozilla12
x86
All
crash, testcase, verified1.9.2
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox9 affected, firefox10 verified, firefox11 verified, firefox12 verified, firefox-esr1010+ verified, blocking1.9.2 .26+, status1.9.2 .26-fixed)

Details

(Whiteboard: [sg:critical][qa!])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
ZDI-CAN-1477:  Mozilla Firefox Ogg Vorbis Decoding Memory Corruption
Remote Code Execution Vulnerability


-- 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 ------------------------

Memory corruption is possible when Firefox is parsing Ogg Vorbis
files. The vulnerability is inside the function static
vorbis_info_floor *floor1_unpack (vorbis_info *vi,oggpack_buffer
*opb), in the file

libvorbis/lib/vorbis_floor1.c:

--- code snip begin ---
	...

  for(j=0,k=0;j<info->partitions;j++){
    count+=info->class_dim[info->partitionclass[j]];
    for(;k<count;k++){
      int t=info->postlist[k+2]=oggpack_read(opb,rangebits);
      if(t<0 || t>=(1<<rangebits))
        goto err_out;
    }
  }
	...
--- code snip end ---

The loop populates the info->postlist array and can be overflowed. The
values which determine the amount to copy are user influenced. The
info->class_dim array is populated with user data, with each element
value being between 1 and 8. The info->partitions value is also taken
from userdata, and can be between 0 and 31. Thus, the total sub-loop
iterations can be 8*31, or 248. Each iteration of the subloop copies
one element (int) into info->postlist, a fixed-size buffer which is
only sized to 65 elements (int). This results in memory corruption and
can be exploited to gain remote code execution.

-- CREDIT ---------------------------------------

This vulnerability was discovered by:

   regenrecht

---
Confirmed crash in trunk from last night with POC at https://crash-stats.mozilla.com/report/index/bp-3f868463-5f01-4da8-966f-b8a642120119. Firefox 9.0.1 crash at https://crash-stats.mozilla.com/report/index/bp-43276710-2344-4ffb-a68c-041232120119.

Password on POC zip is ZDI-CAN-1477.
Attachment #590007 - Attachment description: POC from comment 0 → ZDI POC (password: ZDI-CAN-1477)
Attachment #590007 - Attachment mime type: application/octet-stream → application/java-archive
status-firefox10: --- → affected
status-firefox11: --- → affected
status-firefox12: --- → affected
status-firefox9: --- → affected
(Reporter)

Comment 2

6 years ago
This crashes 1.9.2.25 as well with the POC. https://crash-stats.mozilla.com/report/index/bp-57d2d7b6-2731-4e56-910b-c9e6a2120119
blocking1.9.2: --- → ?
status1.9.2: --- → wanted
Adding upstream in to the loop.
(Assignee)

Comment 4

6 years ago
Created attachment 590062 [details] [diff] [review]
Proposed fix

This is a simple fix, which errors out if the number of values to be read is larger than the array. I'm not confident this is the correct fix, because rangebits can be as large as 15, leaving far more than 63 legal values for the postlist, and I don't see where in the spec a smaller limit is imposed. Waiting for confirmation from Monty.
> This is a simple fix, which errors out if the number of values to be read is
> larger than the array. I'm not confident this is the correct fix, because
> rangebits can be as large as 15, leaving far more than 63 legal values for
> the postlist

Your conclusion/suggested fix is correct.

What the spec is supposed to say is that there are a maximum number of 65 postlist entries; entry 0 is implicit and set to 0, entry 1 is set to 1<<rangebits, and then up to a maximum of 63 more entries are read in that loop.  The code is supposed to enforce that.

Neither limit is there; the spec is silent and the code does not check.  I'm patching upstream spec and code now.
BTW, let me know when I'm OK to add that test vector to our upstream test vector collection.
(Assignee)

Comment 7

6 years ago
Comment on attachment 590062 [details] [diff] [review]
Proposed fix

Okay, with that confirmation, requesting review.
Attachment #590062 - Flags: review?(chris.double)
Comment on attachment 590062 [details] [diff] [review]
Proposed fix

Stealing review.
Attachment #590062 - Flags: review?(chris.double) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/a4d83f2fb3f2
Target Milestone: --- → mozilla12
Flags: in-testsuite?
Comment on attachment 590062 [details] [diff] [review]
Proposed fix

[Approval Request Comment]
Regression caused by (bug #): not a regression
User impact if declined: potential arbitrary code execution
Testing completed (on m-c, etc.): landed on inbound, passes media tests locally
Risk to taking this patch (and alternatives if risky): very low, may reject some invalid Vorbis files that were previously accepted (if it didn't trash enough memory to cause a crash)
Attachment #590062 - Flags: approval1.9.2.26?
Attachment #590062 - Flags: approval-mozilla-release?
Attachment #590062 - Flags: approval-mozilla-beta?
Attachment #590062 - Flags: approval-mozilla-aurora?
Assignee: nobody → tterribe
OS: Mac OS X → All
(Assignee)

Comment 11

6 years ago
(In reply to Monty from comment #6)
> BTW, let me know when I'm OK to add that test vector to our upstream test
> vector collection.

I don't think there's any reason to wait. Though it wasn't clear to me from the above report if this sample contained an actual exploit or just caused a crash (it didn't actually crash my Linux build, though most likely through dumb luck), you _may_ wish to use a different example that just triggers the out-of-bounds write, and doesn't attempt arbitrary code execution.
(Reporter)

Updated

6 years ago
Alias: CVE-2012-0443
(Reporter)

Updated

6 years ago
Alias: CVE-2012-0443 → CVE-2012-0444
https://hg.mozilla.org/mozilla-central/rev/a4d83f2fb3f2
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Comment on attachment 590062 [details] [diff] [review]
Proposed fix

[Triage Comment]
Based upon the low-risk nature of this fix, the sg:crit status, and the fact that this is externally known, we've decided to approve. Please land this fix on Aurora, Beta, and 1.9.2 branches. Please specifically land on Beta 10 and the 1.9.2 branches to make our next release in a week.
Attachment #590062 - Flags: approval1.9.2.26?
Attachment #590062 - Flags: approval1.9.2.26+
Attachment #590062 - Flags: approval-mozilla-release?
Attachment #590062 - Flags: approval-mozilla-release-
Attachment #590062 - Flags: approval-mozilla-beta?
Attachment #590062 - Flags: approval-mozilla-beta+
Attachment #590062 - Flags: approval-mozilla-aurora?
Attachment #590062 - Flags: approval-mozilla-aurora+
status-firefox12: affected → fixed
(Reporter)

Comment 14

6 years ago
I've verified the fix on trunk with the Mac nightly (same machine I verified the PoC on): Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0a1) Gecko/20120123 Firefox/12.0a1
Status: RESOLVED → VERIFIED
https://hg.mozilla.org/releases/mozilla-aurora/rev/b3b7cb84a0d9
https://hg.mozilla.org/releases/mozilla-beta/rev/1bbf2c5b0af8
https://hg.mozilla.org/releases/mozilla-1.9.2/rev/952491790dee
blocking1.9.2: ? → ---
status1.9.2: wanted → .26-fixed
status-firefox10: affected → fixed
status-firefox11: affected → fixed
(In reply to Matthew Gregan [:kinetik] from comment #15)
> https://hg.mozilla.org/releases/mozilla-1.9.2/rev/952491790dee

For completeness, note that the patch landed here differs in one aspect--the patch hunks that applied to libtremor have been removed because libtremor is not present in 1.9.2.  In all other aspects, the patch is identical to that landed on the other trees.
(Reporter)

Updated

6 years ago
status-firefox12: fixed → verified
blocking1.9.2: --- → .26+
status-firefox12: verified → fixed
status-firefox12: fixed → verified
Verified fixed in Firefox 3.6.26 using the POC.
Keywords: verified1.9.2
Whiteboard: [sg:critical] → [sg:critical][qa+]
Verified on latest Fx13(nightly), Fx11(beta), and Fx12(aurora), and Fx10.0.2. On 9.0.1 the POC crashed the application right away, on the fixed builds there's no crash.
status-firefox10: fixed → verified
status-firefox11: fixed → verified
Whiteboard: [sg:critical][qa+] → [sg:critical][qa!]
Comment #18, while using XP.
status-firefox-esr10: --- → verified

Updated

6 years ago
tracking-firefox-esr10: --- → 10+
Attachment #590007 - Attachment is private: true
Group: core-security
Keywords: crash, testcase
Attachment #590007 - Attachment is private: false
You need to log in before you can comment on or make changes to this bug.