Openh264: ASAN heap-buffer-overflow in WelsDec::WelsInitRefList

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: nils, Unassigned)

Tracking

({csectype-bounds, sec-high})

Dependency tree / graph
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox34 wontfix, firefox35 fixed, firefox36 fixed, firefox37 fixed, firefox38 fixed, firefox39 fixed, firefox-esr31 unaffected)

Details

Attachments

(1 attachment)

215 bytes, application/octet-stream
Details
Reporter

Description

5 years ago
The attached testcase crashes an ASAN build of the Firefox branch of openh264 ( https://github.com/cisco/openh264/tree/v1.1-Firefox34 ) as follows:


=================================================================
==1072==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf331ee17 at pc 0x080d5b00 bp 0xfffdf258 sp 0xfffdee3c
WRITE of size 119808 at 0xf331ee17 thread T0
    #0 0x80d5aff in __asan_memset /home/bobthebuilder/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:383:5
    #1 0x8157eee in WelsDec::WelsInitRefList(WelsDec::TagWelsDecoderContext*, int) (/home/nils/264/h264dec-ff+0x8157eee)
    #2 0x8145ae6 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff+0x8145ae6)
    #3 0x8141c9d in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff+0x8141c9d)
    #4 0x8123d6d in WelsDecodeBs (/home/nils/264/h264dec-ff+0x8123d6d)
    #5 0x811d193 in WelsDec::CWelsDecoder::DecodeFrame2(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff+0x811d193)
    #6 0x8115778 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*) (/home/nils/264/h264dec-ff+0x8115778)
    #7 0x8118774 in main (/home/nils/264/h264dec-ff+0x8118774)
    #8 0xf73bca82  (/lib/i386-linux-gnu/libc.so.6+0x19a82)
    #9 0x807cd8b in _start (/home/nils/264/h264dec-ff+0x807cd8b)

0xf331ee17 is located 0 bytes to the right of 59927-byte region [0xf3310400,0xf331ee17)
allocated by thread T0 here:
    #0 0x80f0cdb in malloc /home/bobthebuilder/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
    #1 0x8182c7f in WelsMalloc (/home/nils/264/h264dec-ff+0x8182c7f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bobthebuilder/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:383 __asan_memset
Shadow bytes around the buggy address:
  0x3e663d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e663d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e663d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e663da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e663db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x3e663dc0: 00 00[07]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e663dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e663de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e663df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e663e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e663e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==1072==ABORTING
Component: Video/Audio → WebRTC: Audio/Video
Keywords: csectype-bounds

Comment 1

5 years ago
Thanks for the information. 
Checked it with latest openh264 codec (master), no heap-buffer-overflow found.
It should have been fixed already by early pull requests.
Could you please check if it is OK with latest codec? Thanks.
If OK, we can schedule and update new codec.

Updated

5 years ago
Depends on: 1113777
Component: WebRTC: Audio/Video → OpenH264
Product: Core → Plugins
Version: Trunk → unspecified
Isn't OpenH264 sandboxed?
Flags: needinfo?(dveditz)
We can bump the severity down a little because it's sandboxed, but sandboxing is never perfect (see bug 1117140). "high" might be slightly overrating it, but "moderate" severely underrates the risk.

(from comment 1):
> Checked it with latest openh264 codec (master), no heap-buffer-overflow found.
> It should have been fixed already by early pull requests.

Wayne: are you saying this was found and fixed upstream before this bug report, or merely noting that it is fixed /now/, possibly as a result of this bug filing?
Flags: needinfo?(dveditz)
Keywords: sec-criticalsec-high

Comment 5

5 years ago
Hi Daniel, this bug exists in v1.1-Firefox34 as reported by Nil, but has been fixed already in master of openh264.
That's because master of openh264 development is ahead of v1.1-Firefox34.(from the date we can see, v1.3 is about ready.)
Group: media-core-security
OpenH264 1.3 has this fix and is now downloaded for Firefox 34+ so marking this as fixed.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Flags: sec-bounty?
Flags: sec-bounty? → sec-bounty+
Group: media-core-security

Updated

4 years ago
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.