Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 604420 - <media-libs/openh264-1.7.0: multiple vulnerabilities
Summary: <media-libs/openh264-1.7.0: multiple vulnerabilities
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: http://www.openwall.com/lists/oss-sec...
Whiteboard: B3 [noglsa]
Keywords:
Depends on:
Blocks: 596450 626382
  Show dependency tree
 
Reported: 2017-01-02 18:16 UTC by Thomas Deutschmann
Modified: 2018-04-16 20:43 UTC (History)
3 users (show)

See Also:
Package list:
=media-libs/openh264-1.7.0
Runtime testing required: ---
stable-bot: sanity-check+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann gentoo-dev Security 2017-01-02 18:16:06 UTC
Looks like the openh264-1.6.0 release silently fixed some potential vulnerabilities:

> =================================================================
> ==4637==ERROR: AddressSanitizer: heap-use-after-free on address 0x62f000092410 at pc 0x00000042fa6a bp 0x7ffeffda4c00 sp 0x7ffeffda4bf0
> READ of size 1 at 0x62f000092410 thread T0
>     #0 0x42fa69 in WelsDec::FmoNextMb(WelsDec::TagFmo*, short) (/root/asan/openh264/h264dec+0x42fa69)
>     #1 0x471797 in WelsDec::WelsDecodeSlice(WelsDec::TagWelsDecoderContext*, bool, WelsDec::TagNalUnit*) (/root/asan/openh264/h264dec+0x471797)
>     #2 0x424170 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x424170)
>     #3 0x4275e8 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4275e8)
>     #4 0x40db32 in WelsDecodeBs (/root/asan/openh264/h264dec+0x40db32)
>     #5 0x4089b9 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4089b9)
>     #6 0x404995 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*) (/root/asan/openh264/h264dec+0x404995)
>     #7 0x402be3 in main (/root/asan/openh264/h264dec+0x402be3)
>     #8 0x7f4c8cec082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
>     #9 0x403608 in _start (/root/asan/openh264/h264dec+0x403608)
> 
> 0x62f000092410 is located 24592 bytes inside of 48147-byte region [0x62f00008c400,0x62f000098013)
> freed by thread T0 here:
>     #0 0x7f4c8dba22ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca)
>     #1 0x42f182 in WelsDec::InitFmo(WelsDec::TagFmo*, WelsDec::TagPps*, int, int, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f182)
>     #2 0x42f883 in WelsDec::FmoParamUpdate(WelsDec::TagFmo*, WelsDec::TagSps*, WelsDec::TagPps*, int*, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f883)
>     #3 0x423772 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x423772)
>     #4 0x4275e8 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4275e8)
>     #5 0x40e70f in WelsDecodeBs (/root/asan/openh264/h264dec+0x40e70f)
>     #6 0x406ef9 in WelsDec::CWelsDecoder::DecodeFrame2(unsigned char const*, int, unsigned char**, TagBufferInfo*) [clone .part.3] [clone .constprop.6] (/root/asan/openh264/h264dec+0x406ef9)
>     #7 0x408678 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x408678)
>     #8 0x404995 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*) (/root/asan/openh264/h264dec+0x404995)
>     #9 0x402be3 in main (/root/asan/openh264/h264dec+0x402be3)
>     #10 0x7f4c8cec082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> 
> previously allocated by thread T0 here:
>     #0 0x7f4c8dba2602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
>     #1 0x4b5a78 in WelsCommon::WelsMalloc(unsigned int, char const*, unsigned int) (/root/asan/openh264/h264dec+0x4b5a78)
>     #2 0x4b5b64 in WelsCommon::CMemoryAlign::WelsMalloc(unsigned int, char const*) (/root/asan/openh264/h264dec+0x4b5b64)
>     #3 0x4b5c0f in WelsCommon::CMemoryAlign::WelsMallocz(unsigned int, char const*) (/root/asan/openh264/h264dec+0x4b5c0f)
>     #4 0x42f19a in WelsDec::InitFmo(WelsDec::TagFmo*, WelsDec::TagPps*, int, int, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f19a)
>     #5 0x42f883 in WelsDec::FmoParamUpdate(WelsDec::TagFmo*, WelsDec::TagSps*, WelsDec::TagPps*, int*, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f883)
>     #6 0x423772 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x423772)
>     #7 0x4275e8 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4275e8)
>     #8 0x40db32 in WelsDecodeBs (/root/asan/openh264/h264dec+0x40db32)
>     #9 0x4089b9 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4089b9)
>     #10 0x404995 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*) (/root/asan/openh264/h264dec+0x404995)
>     #11 0x402be3 in main (/root/asan/openh264/h264dec+0x402be3)
>     #12 0x7f4c8cec082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> 
> SUMMARY: AddressSanitizer: heap-use-after-free ??:0 WelsDec::FmoNextMb(WelsDec::TagFmo*, short)
> Shadow bytes around the buggy address:
>   0x0c5e8000a430: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a450: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a460: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a470: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
> =>0x0c5e8000a480: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a490: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a4a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a4b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a4c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>   0x0c5e8000a4d0: 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
>   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
> ==4637==ABORTING


See $URL for the source of the report.

I was yet unable to get further information from other sources.
Comment 1 Thomas Deutschmann gentoo-dev Security 2017-01-02 18:19:05 UTC
@ Maintainer(s): Please bump the package to >=media-libs/openh264-1.6.0 and let us know if it is ready for the stabilization or not.
Comment 2 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2017-07-17 00:54:34 UTC
@maintainer(s), please let us know when you are ready to call for stable or call for it here yourself.
Comment 3 Ian Stakenvicius (RETIRED) gentoo-dev 2017-07-28 01:17:26 UTC
I'm not sure how much testing it's had in the wild, but I'm good to stabilize.
Comment 4 Sergei Trofimovich (RETIRED) gentoo-dev 2017-07-28 07:42:32 UTC
ia64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2017-07-28 14:54:32 UTC
amd64 stable
Comment 6 Agostino Sarubbo gentoo-dev 2017-08-01 06:46:43 UTC
I stabilized because of the chromium security bug which has this bug as a depends on. However, from the stacktrace I don't see the library involved (libopenh264.so) so since it is a read issue in a command-line tool I'd suggest to do not track it as a security issue.
Comment 7 Markus Meier gentoo-dev 2017-08-08 04:31:16 UTC
arm stable
Comment 8 Thomas Deutschmann gentoo-dev Security 2017-08-18 20:11:18 UTC
x86 stable
Comment 9 Matt Turner gentoo-dev 2017-08-31 01:26:35 UTC
alpha stable
Comment 10 Sergei Trofimovich (RETIRED) gentoo-dev 2017-09-26 08:58:05 UTC
ppc/ppc64 stable
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2017-09-26 22:18:42 UTC
hppa stable
Comment 12 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2017-10-20 02:22:53 UTC
@maintainers, please clean.
Comment 13 Christopher Díaz Riveros (RETIRED) gentoo-dev Security 2018-03-18 15:56:10 UTC
cleanup done.

GLSA Vote: No

Thank you all,
Comment 14 Larry the Git Cow gentoo-dev 2018-04-16 20:43:52 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f40f3445169c77e50fc912a4d64d4cc6ca1b6c38

commit f40f3445169c77e50fc912a4d64d4cc6ca1b6c38
Author:     Rolf Eike Beer <eike@sf-mail.de>
AuthorDate: 2018-04-16 20:05:34 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2018-04-16 20:43:36 +0000

    media-libs/openh264: stable 1.7.0-r1 for sparc
    
    Bug: https://bugs.gentoo.org/604420
    Package-Manager: Portage-2.3.24, Repoman-2.3.6
    RepoMan-Options: --include-arches="sparc"

 media-libs/openh264/openh264-1.7.0-r1.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)}