1192226 - (CVE-2015-4506) vp9_init_context_buffers

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Khalil Zhani]

Attachment: 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]

Comment 1

[Jan Gerber]

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

Comment 2

[Khalil Zhani]

This is from https://code.google.com/p/chromium/issues/detail?id=450939

Comment 3

[Jan Gerber]

Attachment: Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch

also limiting the max size to 16384x16384 for vp9.

Comment 4

[Jan Gerber]

Attachment: Bug-1192226-P2.-enable-libvpx-size-limit.patch

and run the updated update.py script

Comment 5

[Khalil Zhani]

This would prevent the overflow issue.

In this bug should restrict vp9 frame sizes to 16384x16384.

Comment 6

[Daniel Veditz [:dveditz]]

On Mac I ran out of application memory and had to force-quit Firefox, but it wasn't an exploitable crash.

Comment 7

[Khalil Zhani]

Can someone repro this bug under Address Sanitizer (ASan) build?

Comment 8

[Ralph Giles (:rillian)]

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?

Comment 9

[Jan Gerber]

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

Comment 10

[Jan Gerber]

Attachment: Bug-1192226-P1.-enable-libvpx-size-limit-in-update.py.patch

Limit video size to 4000x3000 (max video size from VideoUtils.h)

Comment 11

[Jan Gerber]

Attachment: Bug-1192226-P2.-enable-libvpx-size-limit.patch

and run update.py

Comment 12

[Ralph Giles (:rillian)]

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!

Comment 13

[Ralph Giles (:rillian)]

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

Comment 14

[Ralph Giles (:rillian)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4e7adb95567383938336d34367e1fe98934f0227
Bug 1192226 - Enable libvpx size limit in update.py. r=rillian

https://hg.mozilla.org/integration/mozilla-inbound/rev/92d172a5d403efe3a9d89f8049a5291c6ebc8b0e
Bug 1192226 - Apply libvpx size limit. r=rillian

Comment 15

[Ralph Giles (:rillian)]

Jan, could you please test if this is reproducible in dev, beta and esr38 versions and set the affected/unaffected flags appropriately?

Comment 16

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/7eab671c99c5 for build orange:
https://treeherder.mozilla.org/logviewer.html#?job_id=13095423&repo=mozilla-inbound

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 18

[Jan Gerber]

Attachment: 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+

Comment 19

[Ralph Giles (:rillian)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/df49a79ef2ad3f85b581558282cc7570a77f013e
Bug 1192226 - Enable libvpx size limit in update.py. r=rillian

https://hg.mozilla.org/integration/mozilla-inbound/rev/18d6b697556f2a023b67d1b26ad3ea31ca48bb04
Bug 1192226 - Apply libvpx size limit. r=rillian

Comment 20

[Ralph Giles (:rillian)]

(In reply to Jan Gerber from comment #18)

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

tsk tsk. :)

Comment 21

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 22

[Jan Gerber]

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 <[e-mail]>
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.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Can you please nominate these patches for Aurora/Beta/esr38/b2g37 uplift? Thanks!

Comment 24

[Ralph Giles (:rillian)]

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.

Comment 25

[Ralph Giles (:rillian)]

Attachment: 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.

Comment 26

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8651021 [details] [diff] [review]
Bug-1192226-Apply-libvpx-size-limit.-r-rillian.patch

Fixing security issue is good. Aurora42+, Beta41+

Comment 27

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Ralph, should we also uplift to esr38 branch?

Comment 28

[Ralph Giles (:rillian)]

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

Comment 29

[Ralph Giles (:rillian)]

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

Comment 30

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/922b540401d4
https://hg.mozilla.org/releases/mozilla-aurora/rev/4511845571f1

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/589b6ec3180a
https://hg.mozilla.org/releases/mozilla-beta/rev/79cd2fdf68d0

Comment 32

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked as it's a sec issue.

Comment 33

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8653097 [details] [diff] [review]
Apply libvpx size limit to esr38

Approved for uplift to esr38. Stability win!

Comment 34

[Liz Henry (:lizzard) (relman/hg->git project)]

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!

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/1c57c324c353
https://hg.mozilla.org/releases/mozilla-esr38/rev/a6a08555ee5b

Comment 36

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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

Comment 37

[Josh Cheng [:josh]]

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

Not maintaining FxOS 2.2 anymore.