Last Comment Bug 730907 - Need to update libvpx to 1.0.0
: Need to update libvpx to 1.0.0
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: mozilla15
Assigned To: Timothy B. Terriberry (:derf)
:
:
Mentors:
Depends on: 748448 750447
Blocks: 708718
  Show dependency treegraph
 
Reported: 2012-02-27 11:39 PST by Al Billings [:abillings]
Modified: 2012-05-01 09:28 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Update libvpx to v1.0.0 (1.71 MB, patch)
2012-04-27 11:47 PDT, Timothy B. Terriberry (:derf)
cpearce: review+
khuey: review+
Details | Diff | Splinter Review

Description Al Billings [:abillings] 2012-02-27 11:39:43 PST
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 Alex Keybl [:akeybl] 2012-02-27 11:43:29 PST
CC'ing a number of people who will be interested in the outcome of this bug.
Comment 2 Al Billings [:abillings] 2012-02-27 11:43:55 PST
Proper mitre link is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0823.
Comment 3 Al Billings [:abillings] 2012-02-27 11:44:54 PST
CVE-2012-0823

Apparently, bugzilla strips the official URL.
Comment 4 Matthew Gregan [:kinetik] 2012-02-27 11:48:04 PST
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 Alex Keybl [:akeybl] 2012-02-27 11:56:28 PST
(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.
Comment 6 Al Billings [:abillings] 2012-02-27 14:33:56 PST
Can we open this bug or is there a reason not to do so, since we've already fixed the issue in bug 696390?
Comment 7 Matthew Gregan [:kinetik] 2012-02-27 18:39:32 PST
I can't see a reason not to open this bug up.
Comment 8 Timothy B. Terriberry (:derf) 2012-04-27 11:47:53 PDT
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.
Comment 9 Chris Pearce (:cpearce) 2012-04-29 19:21:27 PDT
Comment on attachment 619130 [details] [diff] [review]
Update libvpx to v1.0.0

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

Champion effort.
Comment 10 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-04-29 20:22:28 PDT
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.
Comment 11 Timothy B. Terriberry (:derf) 2012-04-29 20:30:09 PDT
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
Comment 12 Timothy B. Terriberry (:derf) 2012-04-29 20:54:39 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/731c4bc9dd37

Note You need to log in before you can comment on or make changes to this bug.