Closed Bug 1192226 (CVE-2015-4506) Opened 5 years ago Closed 5 years ago

vp9_init_context_buffers

Categories

(Core :: Audio/Video, defect)

All
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox41 + verified
firefox42 + fixed
firefox43 + fixed
firefox-esr38 41+ 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

People

(Reporter: chromium.khalil, Assigned: j)

References

Details

(Keywords: sec-moderate, Whiteboard: [adv-main41+][adv-esr38.3+])

Attachments

(5 files, 3 obsolete files)

Attached video 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]
Component: General → Audio/Video
Product: Firefox → Core
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
also limiting the max size to 16384x16384 for vp9.
Attachment #8645315 - Flags: review?(giles)
and run the updated update.py script
Attachment #8645316 - Flags: review?(giles)
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.
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
(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)
Limit video size to 4000x3000 (max video size from VideoUtils.h)
Attachment #8645315 - Attachment is obsolete: true
Attachment #8649795 - Flags: review?(giles)
and run update.py
Attachment #8649795 - Attachment is obsolete: true
Attachment #8649795 - Flags: review?(giles)
Attachment #8649797 - Flags: review?(giles)
Attachment #8645316 - Flags: review?(giles)
Attachment #8645316 - Attachment is obsolete: true
Attachment #8645316 - Flags: review?(giles)
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: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-wantsec-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.
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
Closed: 5 years ago
status-b2g-v2.2: --- → ?
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Flags: sec-bounty?
Flags: needinfo?(j)
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!
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?
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)
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.
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
Attachment #8653113 - Flags: review?(j) → review+
Flags: qe-verify+
Flags: sec-bounty? → sec-bounty+
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).
Whiteboard: [adv-main41+][adv-esr38.3+]
Alias: CVE-2015-4506
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.