Closed
Bug 1192226
(CVE-2015-4506)
Opened 9 years ago
Closed 9 years ago
vp9_init_context_buffers
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
FIXED
mozilla43
People
(Reporter: chromium.khalil, Assigned: j)
References
Details
(Keywords: sec-moderate, Whiteboard: [adv-main41+][adv-esr38.3+])
Attachments
(5 files, 3 obsolete files)
1.23 KB,
video/webm
|
Details | |
683 bytes,
patch
|
rillian
:
review+
lizzard
:
approval-mozilla-esr38+
|
Details | Diff | Splinter Review |
11.16 KB,
patch
|
j
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
11.83 KB,
patch
|
j
:
review+
lizzard
:
approval-mozilla-esr38+
|
Details | Diff | Splinter Review |
11.82 KB,
patch
|
j
:
review+
jocheng
:
approval-mozilla-b2g37-
|
Details | Diff | Splinter Review |
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•9 years ago
|
Component: General → Audio/Video
Product: Firefox → Core
Assignee | ||
Comment 1•9 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
Reporter | ||
Comment 2•9 years ago
|
||
This is from https://code.google.com/p/chromium/issues/detail?id=450939
Assignee | ||
Comment 3•9 years ago
|
||
also limiting the max size to 16384x16384 for vp9.
Attachment #8645315 -
Flags: review?(giles)
Assignee | ||
Comment 4•9 years ago
|
||
and run the updated update.py script
Attachment #8645316 -
Flags: review?(giles)
Reporter | ||
Comment 5•9 years ago
|
||
This would prevent the overflow issue. In this bug should restrict vp9 frame sizes to 16384x16384.
Comment 6•9 years ago
|
||
On Mac I ran out of application memory and had to force-quit Firefox, but it wasn't an exploitable crash.
Reporter | ||
Comment 7•9 years ago
|
||
Can someone repro this bug under Address Sanitizer (ASan) build?
Comment 8•9 years ago
|
||
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-
Updated•9 years ago
|
Attachment #8645316 -
Flags: review?(giles)
Updated•9 years ago
|
Assignee: nobody → j
Assignee | ||
Comment 9•9 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•9 years ago
|
||
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•9 years ago
|
||
and run update.py
Attachment #8649795 -
Attachment is obsolete: true
Attachment #8649795 -
Flags: review?(giles)
Attachment #8649797 -
Flags: review?(giles)
Assignee | ||
Updated•9 years ago
|
Attachment #8645316 -
Flags: review?(giles)
Assignee | ||
Updated•9 years ago
|
Attachment #8645316 -
Attachment is obsolete: true
Attachment #8645316 -
Flags: review?(giles)
Assignee | ||
Updated•9 years ago
|
Attachment #8649795 -
Attachment is obsolete: false
Attachment #8649795 -
Flags: review?(giles)
Comment 12•9 years ago
|
||
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+
Updated•9 years ago
|
Attachment #8649797 -
Flags: review?(giles) → review+
Comment 13•9 years ago
|
||
[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
Updated•9 years ago
|
Comment 14•9 years ago
|
||
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•9 years ago
|
||
Jan, could you please test if this is reproducible in dev, beta and esr38 versions and set the affected/unaffected flags appropriately?
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
Flags: needinfo?(j)
Comment 17•9 years ago
|
||
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.
Assignee | ||
Comment 18•9 years ago
|
||
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+
Comment 19•9 years ago
|
||
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•9 years ago
|
||
(In reply to Jan Gerber from comment #18) > This time actually run update.py instead of using sed. tsk tsk. :)
Flags: needinfo?(giles)
Comment 21•9 years ago
|
||
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: 9 years ago
status-b2g-v2.1S:
--- → ?
status-b2g-v2.2:
--- → ?
status-b2g-v2.2r:
--- → ?
status-b2g-master:
--- → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Updated•9 years ago
|
Flags: sec-bounty?
Updated•9 years ago
|
Flags: needinfo?(j)
Assignee | ||
Comment 22•9 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)
Comment 23•9 years ago
|
||
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
Flags: needinfo?(j)
Comment 24•9 years ago
|
||
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?
Comment 25•9 years ago
|
||
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•9 years ago
|
Comment 28•9 years ago
|
||
(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•9 years ago
|
||
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?
Updated•9 years ago
|
Attachment #8653097 -
Attachment description: 0002-Bug-1192226-Apply-libvpx-size-limit.-r-rillian-j.patch → Apply libvpx size limit to esr38
Assignee | ||
Updated•9 years ago
|
Attachment #8653113 -
Flags: review?(j) → review+
Comment 30•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/922b540401d4 https://hg.mozilla.org/releases/mozilla-aurora/rev/4511845571f1
Comment 31•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/589b6ec3180a https://hg.mozilla.org/releases/mozilla-beta/rev/79cd2fdf68d0
Updated•9 years ago
|
Flags: qe-verify+
Tracked as it's a sec issue.
Updated•9 years ago
|
Updated•9 years ago
|
Flags: sec-bounty? → sec-bounty+
Updated•9 years ago
|
Group: core-security → core-security-release
Comment 33•9 years ago
|
||
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 34•9 years ago
|
||
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+
Comment 35•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-esr38/rev/1c57c324c353 https://hg.mozilla.org/releases/mozilla-esr38/rev/a6a08555ee5b
Comment 36•9 years ago
|
||
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).
Updated•9 years ago
|
Whiteboard: [adv-main41+][adv-esr38.3+]
Updated•9 years ago
|
Alias: CVE-2015-4506
Updated•9 years ago
|
Comment 37•8 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-
Updated•8 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•