Bug 1192226 (CVE-2015-4506)

vp9_init_context_buffers

RESOLVED FIXED in Firefox 41, Firefox OS master

Status

()

Core
Audio/Video
RESOLVED FIXED
3 years ago
a year ago

People

(Reporter: Khalil Zhani, Assigned: Jan Gerber)

Tracking

({sec-moderate})

unspecified
mozilla43
All
Windows 7
sec-moderate
Points:
---
Bug Flags:
sec-bounty +
in-testsuite ?

Firefox Tracking Flags

(firefox41+ verified, firefox42+ fixed, firefox43+ fixed, firefox-esr3841+ verified, b2g-v2.0 wontfix, b2g-v2.0M wontfix, b2g-v2.1 wontfix, b2g-v2.1S wontfix, b2g-v2.2 affected, b2g-v2.2r affected, b2g-master fixed)

Details

(Whiteboard: [adv-main41+][adv-esr38.3+])

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

3 years ago
Created attachment 8644931 [details]
repro.webm

The attached webm file crash.

0b3df40c 52fb6769 MSVCR120!memset+0x75 [f:\dd\vctools\crt\crtw32\string\i386\memset.asm @ 136]
0b3df428 52fb6960 xul!setup_mi+0x4b [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\common\vp9_alloccommon.c @ 49]
0b3df430 52feca10 xul!vp9_init_context_buffers+0x8 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\common\vp9_alloccommon.c @ 197]
0b3df440 52fecd0f xul!resize_context_buffers+0x95 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\decoder\vp9_decodeframe.c @ 650]
0b3df460 52fec6ff xul!setup_frame_size+0x26 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\decoder\vp9_decodeframe.c @ 659]
0b3df488 52fed4be xul!read_uncompressed_header+0x217 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\decoder\vp9_decodeframe.c @ 1251]
0b3df530 52ff0016 xul!vp9_decode_frame+0x6e [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\decoder\vp9_decodeframe.c @ 1455]
0b3df564 5306601c xul!vp9_receive_compressed_data+0x112 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\decoder\vp9_decoder.c @ 264]
0b3df5e8 530661fa xul!decode_one+0xbe [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\vp9_dx_iface.c @ 312]
0b3df648 53088465 xul!decoder_decode+0x17f [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vp9\vp9_dx_iface.c @ 412]
0b3df664 52ab0456 xul!vpx_codec_decode+0x3e [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\media\libvpx\vpx\src\vpx_decoder.c @ 123]
0b3df848 52ab0795 xul!mozilla::SoftwareWebMVideoDecoder::DecodeVideoFrame+0x1ff [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\dom\media\webm\softwarewebmvideodecoder.cpp @ 153]
0b3df864 52a4d7c3 xul!mozilla::WebMReader::DecodeVideoFrame+0x4c [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\dom\media\webm\webmreader.cpp @ 1049]
0b3df890 52a43ab5 xul!mozilla::MediaDecoderReader::RequestVideoData+0x76 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\dom\media\mediadecoderreader.cpp @ 289]
0b3df8b0 52a4e358 xul!mozilla::detail::MethodCallWithTwoArgs<mozilla::MediaPromise<nsRefPtr<mozilla::VideoData>,enum mozilla::MediaDecoderReader::NotDecodedReason,1>,mozilla::MediaDecoderReader,bool,__int64>::Invoke+0x1c [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\dom\media\mediapromise.h @ 621]
0b3df8c0 52a4fb39 xul!mozilla::detail::ProxyRunnable<mozilla::MediaPromise<nsRefPtr<mozilla::AudioData>,enum mozilla::MediaDecoderReader::NotDecodedReason,1> >::Run+0x12 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\dom\media\mediapromise.h @ 639]
0b3df8e4 51b87509 xul!mozilla::MediaTaskQueue::Runner::Run+0xbd [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\dom\media\mediataskqueue.cpp @ 233]
0b3df90c 51b8f5a6 xul!nsThreadPool::Run+0x238 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\xpcom\threads\nsthreadpool.cpp @ 227]
0b3dfa2c 51c1c455 xul!nsThread::ProcessNextEvent+0x2b2 [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\xpcom\threads\nsthread.cpp @ 861]
0b3dfa48 51c1c3e8 xul!NS_ProcessNextEvent+0x1a [c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\xpcom\glue\nsthreadutils.cpp @ 265]

Updated

3 years ago
Component: General → Audio/Video
Product: Firefox → Core
(Assignee)

Comment 1

3 years ago
Is this an overflow in the webm parser?

ffmpeg reports 65536x65426 [1] while libnestegg/mkvinfo repots 66x34 [2]

[1] ffmpeg -i  repro.webm
Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, smpte170m/unknown/unknown), 65536x65426, SAR 1:1 DAR 32768:32713, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)

[2] mkvinfo repro.webm | grep Pixel
|   + Pixel width: 66
|   + Pixel height: 34

[Nestegg-DBG] element value b0 (ID_PIXEL_WIDTH)  -> 66
[Nestegg-DBG] element value ba (ID_PIXEL_HEIGHT) -> 34
(Assignee)

Comment 3

3 years ago
Created attachment 8645315 [details] [diff] [review]
Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch

also limiting the max size to 16384x16384 for vp9.
Attachment #8645315 - Flags: review?(giles)
(Assignee)

Comment 4

3 years ago
Created attachment 8645316 [details] [diff] [review]
Bug-1192226-P2.-enable-libvpx-size-limit.patch

and run the updated update.py script
Attachment #8645316 - Flags: review?(giles)
(Reporter)

Comment 5

3 years ago
This would prevent the overflow issue.

In this bug should restrict vp9 frame sizes to 16384x16384.
On Mac I ran out of application memory and had to force-quit Firefox, but it wasn't an exploitable crash.
(Reporter)

Comment 7

3 years ago
Can someone repro this bug under Address Sanitizer (ASan) build?
Comment on attachment 8645315 [details] [diff] [review]
Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch

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

Idea is reasonable, but 4000x3000 to match the limits in VideoUtils.h would be better I think. Do those also resolve the crash? https://dxr.mozilla.org/mozilla-central/source/dom/media/VideoUtils.h#156

Have you reported this upstream as well?
Attachment #8645315 - Flags: review?(giles) → review-
Attachment #8645316 - Flags: review?(giles)
Assignee: nobody → j
(Assignee)

Comment 9

3 years ago
(In reply to Ralph Giles (:rillian) from comment #8)
> Comment on attachment 8645315 [details] [diff] [review]
> Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch
> 
> Review of attachment 8645315 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Idea is reasonable, but 4000x3000 to match the limits in VideoUtils.h would
> be better I think. Do those also resolve the crash?
> https://dxr.mozilla.org/mozilla-central/source/dom/media/VideoUtils.h#156
> 

16384 was the vp8 limit and the value chrome uses right now,
but using the limits from VideoUtils.h sounds like it could work too.

> Have you reported this upstream as well?

This was reported in chrome first, so assume it went to libvpx from there.
(https://code.google.com/p/chromium/issues/detail?id=450939)
(Assignee)

Comment 10

3 years ago
Created attachment 8649795 [details] [diff] [review]
Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch

Limit video size to 4000x3000 (max video size from VideoUtils.h)
Attachment #8645315 - Attachment is obsolete: true
Attachment #8649795 - Flags: review?(giles)
(Assignee)

Comment 11

3 years ago
Created attachment 8649797 [details] [diff] [review]
Bug-1192226-P2.-enable-libvpx-size-limit.patch

and run update.py
Attachment #8649795 - Attachment is obsolete: true
Attachment #8649795 - Flags: review?(giles)
Attachment #8649797 - Flags: review?(giles)
(Assignee)

Updated

3 years ago
Attachment #8645316 - Flags: review?(giles)
(Assignee)

Updated

3 years ago
Attachment #8645316 - Attachment is obsolete: true
Attachment #8645316 - Flags: review?(giles)
(Assignee)

Updated

3 years ago
Attachment #8649795 - Attachment is obsolete: false
Attachment #8649795 - Flags: review?(giles)
Comment on attachment 8649795 [details] [diff] [review]
Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch

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

thanks!
Attachment #8649795 - Flags: review?(giles) → review+
Attachment #8649797 - Flags: review?(giles) → review+
[Tracking Requested - why for this release]:

Requesting tracking and sec rating for this, so we can get the mitigation landed. Note per comment #9 this vulnerability is public in upstream's issue tracker since Aug 5. Google rated it sec-medium.
status-firefox41: --- → ?
status-firefox42: --- → ?
status-firefox43: --- → affected
status-firefox-esr38: --- → ?
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
tracking-firefox43: --- → ?
tracking-firefox-esr38: --- → ?
Keywords: sec-want
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-want → sec-moderate
Jan, could you please test if this is reproducible in dev, beta and esr38 versions and set the affected/unaffected flags appropriately?
I don't think we necessarily need to track this since it's rated sec-moderate and we're not sure which versions it affects.
I'll track it for 42 and 43 for now.
tracking-firefox42: ? → +
tracking-firefox43: ? → +
(Assignee)

Comment 18

3 years ago
Created attachment 8651021 [details] [diff] [review]
Bug-1192226-Apply-libvpx-size-limit.-r-rillian.patch

ups, looks like my search and replace operation failed - sorry about that.
This time actually run update.py instead of using sed.
Can you land this again rillian?

carry r+
Attachment #8649797 - Attachment is obsolete: true
Flags: needinfo?(j) → needinfo?(giles)
Attachment #8651021 - Flags: review+
(In reply to Jan Gerber from comment #18)

> This time actually run update.py instead of using sed.

tsk tsk. :)
Flags: needinfo?(giles)
https://hg.mozilla.org/mozilla-central/rev/df49a79ef2ad
https://hg.mozilla.org/mozilla-central/rev/18d6b697556f

Would be good to know how far back this goes.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-b2g-v2.1S: --- → ?
status-b2g-v2.2: --- → ?
status-b2g-v2.2r: --- → ?
status-b2g-master: --- → fixed
status-firefox43: affected → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Flags: sec-bounty?
Flags: needinfo?(j)
(Assignee)

Comment 22

3 years ago
I think this might affects all version with VP9 support.
The option to limit the size in libvpx was added in:

commit 943e43273b0a7369d07714e7fd2e19fecfb11c7c
Author: Jim Bankoski <jimbankoski@google.com>
Date:   Thu Jul 17 06:31:50 2014 -0700

First Firefox version to support VP9 was Firefox 28 (Bug 833023)

It crashes 41 here and older version for sure run out of memory.
Flags: needinfo?(j)
Can you please nominate these patches for Aurora/Beta/esr38/b2g37 uplift? Thanks!
status-b2g-v2.0: --- → wontfix
status-b2g-v2.0M: --- → wontfix
status-b2g-v2.1: --- → wontfix
status-b2g-v2.1S: ? → affected
status-b2g-v2.2: ? → affected
status-b2g-v2.2r: ? → affected
status-firefox41: ? → affected
status-firefox42: ? → affected
status-firefox-esr38: ? → affected
Flags: needinfo?(j)
Comment on attachment 8651021 [details] [diff] [review]
Bug-1192226-Apply-libvpx-size-limit.-r-rillian.patch

Requesting Aurora/Beta uplift for both patches in this bug. First part in not part of the build but should land for consistency.

Approval Request Comment
[Feature/regressing bug #]: vp9 playback support
[User impact if declined]: Specially crafted content can crash firefox.
[Describe test coverage new/current, TreeHerder]: Landed on m-c some days ago.
[Risks and why]: Risk is low. This changes the build configuration of a third-party library to reject the bad files we wouldn't play anyway. There should be no effect on normal content.
[String/UUID change made/needed]: None.
Attachment #8651021 - Flags: approval-mozilla-beta?
Attachment #8651021 - Flags: approval-mozilla-aurora?
Created attachment 8653097 [details] [diff] [review]
Apply libvpx size limit to esr38

Backport of part 2 to esr37. This should land alongside part 1, which applies cleanly and is not part of the build.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
Easy fix to a crash vulnerability.
User impact if declined: crafted video content can crash firefox
Fix Landed on Version: 43.
Risk to taking this patch (and alternatives if risky): Risk is low. This changed the build configuration of a 3rd-party library to reject corrupt files we wouldn't play anyway. Easy to back out as well.
String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #8653097 - Flags: review?(j)
Attachment #8653097 - Flags: approval-mozilla-esr38?
Comment on attachment 8651021 [details] [diff] [review]
Bug-1192226-Apply-libvpx-size-limit.-r-rillian.patch

Fixing security issue is good. Aurora42+, Beta41+
Attachment #8651021 - Flags: approval-mozilla-beta?
Attachment #8651021 - Flags: approval-mozilla-beta+
Attachment #8651021 - Flags: approval-mozilla-aurora?
Attachment #8651021 - Flags: approval-mozilla-aurora+
Ralph, should we also uplift to esr38 branch?
Flags: needinfo?(giles)
(Assignee)

Updated

3 years ago
Flags: needinfo?(j)
Flags: needinfo?(giles)
Attachment #8653097 - Flags: review?(j) → review+
(In reply to Ritu Kothari (:ritu) from comment #27)
> Ralph, should we also uplift to esr38 branch?

We should. Was just preparing backports since the fix doesn't apply cleanly to the older branches.
Created attachment 8653113 [details] [diff] [review]
Part 2 - apply libvpx change to b2g37_v2_2

Backport of part 2 to the b2g37_v2_2 tree. The should be applied along with part 1, which applies cleanly and is not part of the build.

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): vp9 playback
User impact if declined: Crafted content can crash gecko
Testing completed: Landed on m-c, regressions should be convered by mochitests.
Risk to taking this patch (and alternatives if risky): Risk is low. This changes the build configuration of a third-party library to reject files we wouldn't play anyway. Should have no effect on valid web content.
String or UUID changes made by this patch: None
Attachment #8653113 - Flags: review?(j)
Attachment #8653113 - Flags: approval-mozilla-b2g37?
Attachment #8653097 - Attachment description: 0002-Bug-1192226-Apply-libvpx-size-limit.-r-rillian-j.patch → Apply libvpx size limit to esr38
(Assignee)

Updated

3 years ago
Attachment #8653113 - Flags: review?(j) → review+
Flags: qe-verify+
Tracked as it's a sec issue.
tracking-firefox41: ? → +
tracking-firefox-esr38: ? → 41+
Flags: sec-bounty? → sec-bounty+

Updated

3 years ago
Group: core-security → core-security-release
Comment on attachment 8653097 [details] [diff] [review]
Apply libvpx size limit to esr38

Approved for uplift to esr38. Stability win!
Attachment #8653097 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
Comment on attachment 8649795 [details] [diff] [review]
Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch

Part1 should be uplifted to all branches including esr (alongside the particular patch for esr). Just making sure!
Attachment #8649795 - Flags: approval-mozilla-esr38+
I reproduced the crash whenever clicking the play button twice for the attached webm file using Firefox 41 beta 4 on Windows 7 x64. The crash no longer reproduces with Firefox 41 Beta 7 and latest ESR 38 build from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-esr38-win32/latest/ (BuildID: 20150903104525).
status-firefox41: fixed → verified
status-firefox-esr38: fixed → verified
Flags: qe-verify+

Updated

3 years ago
Whiteboard: [adv-main41+][adv-esr38.3+]

Updated

3 years ago
Alias: CVE-2015-4506
status-b2g-v2.1S: affected → wontfix

Comment 37

2 years ago
Comment on attachment 8653113 [details] [diff] [review]
Part 2 - apply libvpx change to b2g37_v2_2

Not maintaining FxOS 2.2 anymore.
Attachment #8653113 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37-
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.