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

Status: RESOLVED FIXED

(Core :: Audio/Video: GMP, defect)

Description

[Nils]

Attachment: repro.264 (minimised testcase)

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

Comment 1

[wayne]

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.

Comment 2

[Bobby Holley (:bholley)]

Isn't OpenH264 sandboxed?

Comment 3

[Bobby Holley (:bholley)]

See bug 1114996 comment 4.

Comment 4

[Daniel Veditz [: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?

Comment 5

[wayne]

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

Comment 6

[Ethan Hugg [:ehugg]]

OpenH264 1.3 has this fix and is now downloaded for Firefox 34+ so marking this as fixed.