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.
CC'ing a number of people who will be interested in the outcome of this bug.
Proper mitre link is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0823.
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.
(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.
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.
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 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+
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
Target Milestone: --- → mozilla15
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.