New issue
Advanced search Search tips

Issue 842265 link

Starred by 3 users

Security: WebRTC: Use-after-free in VP8 Block Decoding

Project Member Reported by natashenka@google.com, May 11 2018

Issue description

There is a use-after-free in VP8 block decoding in WebRTC. The contents of the freed block is then treated a pointer, leading to a crash in WebRTC.

==20098==ERROR: AddressSanitizer: heap-use-after-free on address 0x6330000a9491 at pc 0x0000014cde2f bp 0x7ff20616d7e0 sp 0x7ff20616d7d8
READ of size 1 at 0x6330000a9491 thread T5 (DecodingThread)
    #0 0x14cde2e in vp8_deblock third_party/libvpx/source/libvpx/vp8/common/postproc.c:85:37
    #1 0x14ce6b2 in vp8_post_proc_frame third_party/libvpx/source/libvpx/vp8/common/postproc.c:354:5
    #2 0x14963a4 in vp8dx_get_raw_frame third_party/libvpx/source/libvpx/vp8/decoder/onyxd_if.c:404:9
    #3 0x149221f in vp8_get_frame third_party/libvpx/source/libvpx/vp8/vp8_dx_iface.c:465:14
    #4 0x148c118 in webrtc::LibvpxVp8Decoder::Decode(webrtc::EncodedImage const&, bool, webrtc::RTPFragmentationHeader const*, webrtc::CodecSpecificInfo const*, long) modules/video_coding/codecs/vp8/libvpx_vp8_decoder.cc:254:9
    #5 0x1b930b4 in webrtc::VCMGenericDecoder::Decode(webrtc::VCMEncodedFrame const&, long) modules/video_coding/generic_decoder.cc:233:29
    #6 0x1b6fad3 in webrtc::vcm::VideoReceiver::Decode(webrtc::VCMEncodedFrame const&) modules/video_coding/video_receiver.cc:374:19
    #7 0x1b6ff19 in webrtc::vcm::VideoReceiver::Decode(webrtc::VCMEncodedFrame const*) modules/video_coding/video_receiver.cc:340:10
    #8 0x1af33e4 in webrtc::internal::VideoReceiveStream::Decode() video/video_receive_stream.cc:433:41
    #9 0x1aedc8f in webrtc::internal::VideoReceiveStream::DecodeThreadFunction(void*) video/video_receive_stream.cc:410:49
    #10 0x6544d3 in Run rtc_base/platform_thread.cc:163:5
    #11 0x6544d3 in rtc::PlatformThread::StartThread(void*) rtc_base/platform_thread.cc:81
    #12 0x7ff22125e493 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7493)

0x6330000a9491 is located 3217 bytes inside of 96619-byte region [0x6330000a8800,0x6330000c016b)
freed by thread T5 (DecodingThread) here:
    #0 0x59e3e2 in __interceptor_free /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:68:3
    #1 0x1492a54 in vp8_de_alloc_frame_buffers third_party/libvpx/source/libvpx/vp8/common/alloccommon.c:41:3
    #2 0x1492b0c in vp8_alloc_frame_buffers third_party/libvpx/source/libvpx/vp8/common/alloccommon.c:54:3
    #3 0x149126c in vp8_decode third_party/libvpx/source/libvpx/vp8/vp8_dx_iface.c:374:13
    #4 0x14d42c5 in vpx_codec_decode third_party/libvpx/source/libvpx/vpx/src/vpx_decoder.c:116:11
    #5 0x148c0a1 in webrtc::LibvpxVp8Decoder::Decode(webrtc::EncodedImage const&, bool, webrtc::RTPFragmentationHeader const*, webrtc::CodecSpecificInfo const*, long) modules/video_coding/codecs/vp8/libvpx_vp8_decoder.cc:245:7
    #6 0x1b930b4 in webrtc::VCMGenericDecoder::Decode(webrtc::VCMEncodedFrame const&, long) modules/video_coding/generic_decoder.cc:233:29
    #7 0x1b6fad3 in webrtc::vcm::VideoReceiver::Decode(webrtc::VCMEncodedFrame const&) modules/video_coding/video_receiver.cc:374:19
    #8 0x1b6ff19 in webrtc::vcm::VideoReceiver::Decode(webrtc::VCMEncodedFrame const*) modules/video_coding/video_receiver.cc:340:10
    #9 0x1af33e4 in webrtc::internal::VideoReceiveStream::Decode() video/video_receive_stream.cc:433:41
    #10 0x1aedc8f in webrtc::internal::VideoReceiveStream::DecodeThreadFunction(void*) video/video_receive_stream.cc:410:49
    #11 0x6544d3 in Run rtc_base/platform_thread.cc:163:5
    #12 0x6544d3 in rtc::PlatformThread::StartThread(void*) rtc_base/platform_thread.cc:81
    #13 0x7ff22125e493 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7493)

previously allocated by thread T5 (DecodingThread) here:
    #0 0x59e723 in __interceptor_malloc /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:88:3
    #1 0x1530d92 in vpx_calloc third_party/libvpx/source/libvpx/vpx_mem/vpx_mem.c:60:10
    #2 0x1492e12 in vp8_alloc_frame_buffers third_party/libvpx/source/libvpx/vp8/common/alloccommon.c:90:7
    #3 0x149126c in vp8_decode third_party/libvpx/source/libvpx/vp8/vp8_dx_iface.c:374:13
    #4 0x14d42c5 in vpx_codec_decode third_party/libvpx/source/libvpx/vpx/src/vpx_decoder.c:116:11
    #5 0x148c0a1 in webrtc::LibvpxVp8Decoder::Decode(webrtc::EncodedImage const&, bool, webrtc::RTPFragmentationHeader const*, webrtc::CodecSpecificInfo const*, long) modules/video_coding/codecs/vp8/libvpx_vp8_decoder.cc:245:7
    #6 0x1b930b4 in webrtc::VCMGenericDecoder::Decode(webrtc::VCMEncodedFrame const&, long) modules/video_coding/generic_decoder.cc:233:29
    #7 0x1b6fad3 in webrtc::vcm::VideoReceiver::Decode(webrtc::VCMEncodedFrame const&) modules/video_coding/video_receiver.cc:374:19
    #8 0x1b6ff19 in webrtc::vcm::VideoReceiver::Decode(webrtc::VCMEncodedFrame const*) modules/video_coding/video_receiver.cc:340:10
    #9 0x1af33e4 in webrtc::internal::VideoReceiveStream::Decode() video/video_receive_stream.cc:433:41
    #10 0x1aedc8f in webrtc::internal::VideoReceiveStream::DecodeThreadFunction(void*) video/video_receive_stream.cc:410:49
    #11 0x6544d3 in Run rtc_base/platform_thread.cc:163:5
    #12 0x6544d3 in rtc::PlatformThread::StartThread(void*) rtc_base/platform_thread.cc:81
    #13 0x7ff22125e493 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7493)

Thread T5 (DecodingThread) created by T0 here:
    #0 0x5871ed in __interceptor_pthread_create /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/asan_interceptors.cc:210:3
    #1 0x654760 in rtc::PlatformThread::Start() rtc_base/platform_thread.cc:103:3
    #2 0x1af010e in webrtc::internal::VideoReceiveStream::Start() video/video_receive_stream.cc:227:18
    #3 0x5d9f4d in webrtc::RtpReplay() video/replay.cc:614:19
    #4 0x5dd5fe in main video/replay.cc:700:3
    #5 0x7ff21f8f92b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: heap-use-after-free third_party/libvpx/source/libvpx/vp8/common/postproc.c:85:37 in vp8_deblock
Shadow bytes around the buggy address:
  0x0c668000d240: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d250: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d260: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d270: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d280: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c668000d290: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d2a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d2b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d2c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d2d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c668000d2e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==20098==ABORTING

To reproduce this issue:

1) replace video/replay.cc with the attached version, and build it with asan (ninja -C out/asan video_replay). Note that this file adds the ability to load a full receiver config to the video replay tool, I'm hoping to eventually get this change committed to WebRTC.

2) Download the attached files config3.txt and heapuaf

3) run video_replay --input_file  heapuaf  --config_file config3.txt

This issue affects any browser that supports VP8, and can be reached by loading a single webpage (though some browsers will prompt for permissions). It also affects native clients (such as mobile applications) that use webrtc and support VP8, though the user has to place or answer a video call for their client to be in the state where this issue is reachable.  

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.
 
replay.cc
21.3 KB View Download
heapuaf
8.0 KB View Download
config3.txt
1023 bytes View Download

Comment 1 by rsesek@chromium.org, May 13 2018

Components: Internals>Media>Codecs
Labels: M-67 Security_Severity-High Security_Impact-Stable OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows Pri-1
Owner: yunqingwang@chromium.org
Status: Assigned (was: Unconfirmed)
yunqingwang: Can you take a look at this please?
Cc: marpan@chromium.org jianj@chromium.org

Comment 3 by jianj@chromium.org, May 14 2018

Cc: yunqingwang@google.com
Updated steps for reproducing this issue:

1) apply new.patch to webrtc/src
2) build video replay (ninja -C out/asan video_replay)
3) put the two attached test files in the same directory (for example, testdir)
4) run ./out/asan/video_replay --input_file testdir/test
new.patch
22.4 KB Download
test_config
1.9 KB View Download
test_rtpdump
8.0 KB View Download

Comment 5 by jianj@chromium.org, May 23 2018

Cc: jzern@chromium.org
Owner: jianj@chromium.org

Comment 6 by jianj@chromium.org, May 23 2018

This is caused by a no show frame with resolution change. When the frame size changes, frame buffer is freed and then re-allocated. But it's a no show frame, so cm->show_frame_mi won't be updated with the re-allocated cm->mi.

However, cm->show_frame_mi is used in postproc, which causes use-after-free.

Upstream fix is here:
https://chromium-review.googlesource.com/c/webm/libvpx/+/1070753

It'll be rolled after it gets in libvpx.
Project Member

Comment 7 by bugdroid1@chromium.org, May 25 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/webm/libvpx/+/52add5896661d186dec284ed646a4b33b607d2c7

commit 52add5896661d186dec284ed646a4b33b607d2c7
Author: Jerome Jiang <jianj@google.com>
Date: Fri May 25 17:46:26 2018

VP8: Fix use-after-free in postproc.

The pointer in vp8 postproc refers to show_frame_mi which is only
updated on show frame. However, when there is a no-show frame which also
changes the size (thus new frame buffers allocated), show_frame_mi is
not updated with new frame buffer memory.

Change the pointer in postproc to mi which is always updated.

Bug:  842265 
Change-Id: I33874f2112b39f74562cba528432b5f239e6a7bd

[modify] https://crrev.com/52add5896661d186dec284ed646a4b33b607d2c7/vp8/common/postproc.c

Comment 8 by jianj@chromium.org, May 25 2018

Will be rolled into chromium next week.
Project Member

Comment 9 by bugdroid1@chromium.org, May 29 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/17eb61099e1b47fdcce709cffedec412a51f4a1f

commit 17eb61099e1b47fdcce709cffedec412a51f4a1f
Author: Jerome Jiang <jianj@google.com>
Date: Tue May 29 21:48:08 2018

Roll src/third_party/libvpx/source/libvpx/ 36825590b..2b08f8907 (3 commits)

https://chromium.googlesource.com/webm/libvpx.git/+log/36825590ba67..2b08f89076d1

$ git log 36825590b..2b08f8907 --date=short --no-merges --format='%ad %ae %s'
2018-05-25 marpan vp9-realtime: Move frame dropper to after scene detection.
2018-05-28 marpan vp9-svc: Fix to allowed value of max_consec_drop.
2018-05-23 jianj VP8: Fix use-after-free in postproc.

Created with:
  roll-dep src/third_party/libvpx/source/libvpx
R=johannkoenig@google.com

BUG= 842265 

Change-Id: I3accf4ed9e8ce3ad6277c5ba9f34f380d4bb4f76
Reviewed-on: https://chromium-review.googlesource.com/1076899
Reviewed-by: Johann Koenig <johannkoenig@google.com>
Commit-Queue: Jerome Jiang <jianj@google.com>
Cr-Commit-Position: refs/heads/master@{#562607}
[modify] https://crrev.com/17eb61099e1b47fdcce709cffedec412a51f4a1f/DEPS
[modify] https://crrev.com/17eb61099e1b47fdcce709cffedec412a51f4a1f/third_party/libvpx/README.chromium
[modify] https://crrev.com/17eb61099e1b47fdcce709cffedec412a51f4a1f/third_party/libvpx/source/config/vpx_version.h

Comment 10 by jianj@chromium.org, May 29 2018

Status: Fixed (was: Assigned)
Fix has been rolled into chromium.

Please verify.
Project Member

Comment 11 by sheriffbot@chromium.org, May 30 2018

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member

Comment 12 by sheriffbot@chromium.org, Jun 8

Labels: Merge-Request-68
Project Member

Comment 13 by sheriffbot@chromium.org, Jun 8

Labels: -Merge-Request-68 Hotlist-Merge-Review Merge-Review-68
This bug requires manual review: DEPS changes referenced in bugdroid comments.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-68 Merge-Approved-68
Approved - branch:3440
Project Member

Comment 15 by sheriffbot@chromium.org, Jun 12

Cc: abdulsyed@google.com
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 16 by bugdroid1@chromium.org, Jun 12

Labels: merge-merged-m68-3440
The following revision refers to this bug:
  https://chromium.googlesource.com/webm/libvpx/+/b501b19a5d6779d30bc8e3f0a6dd134d229b6655

commit b501b19a5d6779d30bc8e3f0a6dd134d229b6655
Author: Jerome Jiang <jianj@google.com>
Date: Tue Jun 12 21:50:44 2018

VP8: Fix use-after-free in postproc.

The pointer in vp8 postproc refers to show_frame_mi which is only
updated on show frame. However, when there is a no-show frame which also
changes the size (thus new frame buffers allocated), show_frame_mi is
not updated with new frame buffer memory.

Change the pointer in postproc to mi which is always updated.

Bug:  842265 
Change-Id: I33874f2112b39f74562cba528432b5f239e6a7bd
(cherry picked from commit 52add5896661d186dec284ed646a4b33b607d2c7)

[modify] https://crrev.com/b501b19a5d6779d30bc8e3f0a6dd134d229b6655/vp8/common/postproc.c

Project Member

Comment 17 by sheriffbot@chromium.org, Jun 18

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: abdulsyed@chromium.org
Pls merge you change to M68 branch 3440 ASAP so we can pick it up for this week Beta release. Merge has to happen latest by 1:00 PM PT tomorrow, Tuesday (06/19), so we can pick it up for Wednesday Beta release.




Project Member

Comment 19 by bugdroid1@chromium.org, Jun 18

Labels: -merge-approved-68 merge-merged-3440
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c53bb62cbaf0918be60392931be7415343915aeb

commit c53bb62cbaf0918be60392931be7415343915aeb
Author: Jerome Jiang <jianj@google.com>
Date: Mon Jun 18 22:14:30 2018

Update DEPS for libvpx merge.

Bug:  842265 
Change-Id: Ib5478e4494ab51d8c43146276b94714f29e9db17
Reviewed-on: https://chromium-review.googlesource.com/1099764
Reviewed-by: James Zern <jzern@google.com>
Cr-Commit-Position: refs/branch-heads/3440@{#426}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/c53bb62cbaf0918be60392931be7415343915aeb/DEPS

The fix has been merged.
Labels: Release-0-M68
Labels: CVE-2018-6155 CVE_description-missing
Project Member

Comment 23 by sheriffbot@chromium.org, Sep 5

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment