Need to update libvpx to 1.0.0

RESOLVED FIXED in mozilla15

Status

()

Core
Audio/Video
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: abillings, Assigned: derf)

Tracking

Trunk
mozilla15
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Mitre reports that the VP8 Codec SDK (libvpx) before 1.0.0 "Duclair" allows remote attackers to cause a denial of service (application crash) via (1) unspecified "corrupt input" or (2) by "starting decoding from a P-frame," which triggers an out-of-bounds read, related to "the clamping of motion vectors in SPLITMV blocks".

See:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0823
http://code.google.com/p/webm/source/browse/CHANGELOG?repo=libvpx
http://www.openwall.com/lists/oss-security/2012/01/30/2
http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released.html

So, I believe we need to update to the 1.0.0 version of libvpx since this is publicly disclosed now.

A testcase would be nice to repro the DOS.

Comment 1

5 years ago
CC'ing a number of people who will be interested in the outcome of this bug.
(Reporter)

Comment 2

5 years ago
Proper mitre link is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0823.
(Reporter)

Comment 3

5 years ago
CVE-2012-0823

Apparently, bugzilla strips the official URL.
The SPLITMV fix landed in November (bug 696390).  It'd still be a good idea to update to the latest libvpx release so that it's obvious we're up to date.

Comment 5

5 years ago
(In reply to Matthew Gregan [:kinetik] from comment #4)
> The SPLITMV fix landed in November (bug 696390).  It'd still be a good idea
> to update to the latest libvpx release so that it's obvious we're up to date.

Just spoke with kinetik in IRC to clarify. He let me know that he believes we're not vulnerable now that bug 696390 is fixed.

On a separate note - it's not  clear that we'd need to chemspill for this DOS if it wasn't fixed in bug 696390. Crashing (DOS) when opening a webm video seems like an "stop hitting yourself" sort of bug.
Alias: CVE-2012-0823
Keywords: crash
Whiteboard: [sg:dos]
(Reporter)

Comment 6

5 years ago
Can we open this bug or is there a reason not to do so, since we've already fixed the issue in bug 696390?
Summary: DOS crash in VP8 Codec 0.9.7 - Need to update libvpx to 1.0.0 → Need to update libvpx to 1.0.0
I can't see a reason not to open this bug up.
Group: core-security
(Assignee)

Updated

5 years ago
Depends on: 748448
(Assignee)

Comment 8

5 years ago
Created attachment 619130 [details] [diff] [review]
Update libvpx to v1.0.0

khuey: You only need to review the build-system bits (configure.in and Makefile.in changes).

cpearce: If you need me to break out the series of patches we now apply into individual attachments to make reviewing them in bugzilla easier, I'm happy to do so.

Sorry for the delay on this. This update required an unusual amount of work to get things into decent shape.

The new MFQE post-processing filter in the decoder started using a number of variance functions from the encoder, but outside the existing run-time CPU detection framework (which was all still in the encoder structures, which we normally don't compile). This is fixed upstream, but that fix was done after the entire RTCD framework was rewritten. That rewrite is probably too invasive to backport to this release, and had at least one known issue that wasn't fixed until earlier this week, so I chose to move everything within the existing RTCD framework instead (see I256a37c6.patch and variance-invoke.patch; the latter is obsoleted by the new RTCD framework and shouldn't need to go upstream).

I'll work on getting textrels.patch (needed to keep native Fennec from crashing on startup) and compile_errors.patch upstream as well (I had pointed them at the latter before, but the problem has only gotten worse since then, so I'll be more proactive about it). Maybe I can rekindle their interest in solaris.patch, too, so we can stop carrying that one. stdint.patch should already be upstream, but didn't make the v1.0.0 release.
Assignee: nobody → tterribe
Status: NEW → ASSIGNED
Attachment #619130 - Flags: review?(khuey)
Attachment #619130 - Flags: review?(cpearce)
(Assignee)

Updated

5 years ago
Blocks: 708718
(Assignee)

Updated

5 years ago
Keywords: crash
Whiteboard: [sg:dos]
Comment on attachment 619130 [details] [diff] [review]
Update libvpx to v1.0.0

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

Champion effort.
Attachment #619130 - Flags: review?(cpearce) → review+
Comment on attachment 619130 [details] [diff] [review]
Update libvpx to v1.0.0

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

Doesn't look too crazy.
Attachment #619130 - Flags: review?(khuey) → review+
(Assignee)

Comment 11

5 years ago
Greenish on try:
Decoder only: https://tbpl.mozilla.org/?tree=Try&rev=47b6d7f1589c
Plus error concealment and encoder: https://tbpl.mozilla.org/?tree=Try&rev=275fa2f2ab18
(Assignee)

Comment 12

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/731c4bc9dd37
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/731c4bc9dd37
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 750447
You need to log in before you can comment on or make changes to this bug.