The libmp4v2 library through version 2.1.0 is vulnerable to an integer overflow and resultant heap-based buffer overflow when resizing an MP4Array for the ftyp atom in mp4array.h. An attacker could exploit this to cause a denial of service via crafted MP4 file. External Reference: http://www.openwall.com/lists/oss-security/2018/07/16/1
Created libmp4v2 tracking bugs for this issue: Affects: epel-all [bug 1601676] Affects: fedora-all [bug 1601675]
Reproduced with libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64: sh-4.4# mp4info c2.mp4 2>&1 | ./asan_symbolizer.py -d ================================================================= ==280==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f341a8ff7e8 at pc 0x7f341e63a26e bp 0x7ffc12ea1d60 sp 0x7ffc12ea1d50 WRITE of size 8 at 0x7f341a8ff7e8 thread T0 #0 0x7f341e63a26d in MP4FileInfo /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4property.cpp:349 #1 0x7f341e5b9501 in mp4v2::impl::MP4FtypAtom::Read() /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/atom_ftyp.cpp:56 #2 0x7f341e5fc02f in MP4SetTrackDurationPerChunk /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4atom.cpp:195 #3 0x7f341e5fdbb0 in MP4SetTrackDurationPerChunk /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4atom.cpp:429 #4 0x7f341e5fc4ab in MP4SetTrackDurationPerChunk /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4atom.cpp:235 #5 0x7f341e60d137 in __gnu_cxx::new_allocator<std::_List_node<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::max_size() const /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4file.cpp:430 #6 0x7f341e609ee9 in __gnu_cxx::new_allocator<std::_List_node<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::max_size() const /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4file.cpp:96 #7 0x7f341e5e7594 in MP4Read (/lib64/libmp4v2.so.2+0x1c8594) #8 0x7f341e6370aa in MP4FileInfo (/lib64/libmp4v2.so.2+0x2180aa) #7 0x40354e in main /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/util/mp4info.cpp:77 #10 0x7f341d7a0f29 in __libc_start_main (/lib64/libc.so.6+0x20f29) #8 0x403049 in ?? ??:0 0x7f341a8ff7e8 is located 0 bytes to the right of 4294967272-byte region [0x7f331a8ff800,0x7f341a8ff7e8) allocated by thread T0 here: #0 0x7f341ebfbc40 in realloc (/lib64/libasan.so.4+0xdec40) #9 0x7f341e5ad314 in mp4v2::impl::MP4Realloc(void*, unsigned int) /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4util.h:80 #10 0x7f341e644ec4 in MP4FileInfo /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4array.h:136 #11 0x7f341e63a22a in MP4FileInfo /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4property.cpp:346 #12 0x7f341e5b9501 in mp4v2::impl::MP4FtypAtom::Read() /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/atom_ftyp.cpp:56 #13 0x7f341e5fc02f in MP4SetTrackDurationPerChunk /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4atom.cpp:195 #14 0x7f341e5fdbb0 in MP4SetTrackDurationPerChunk /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4atom.cpp:429 #15 0x7f341e5fc4ab in MP4SetTrackDurationPerChunk /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4atom.cpp:235 #16 0x7f341e60d137 in __gnu_cxx::new_allocator<std::_List_node<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::max_size() const /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4file.cpp:430 #17 0x7f341e609ee9 in __gnu_cxx::new_allocator<std::_List_node<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::max_size() const /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/src/mp4file.cpp:96 #10 0x7f341e5e7594 in MP4Read (/lib64/libmp4v2.so.2+0x1c8594) #11 0x7f341e6370aa in MP4FileInfo (/lib64/libmp4v2.so.2+0x2180aa) #18 0x40354e in main /usr/src/debug/libmp4v2-2.1.0-0.11.trunkREV507.fc27.x86_64/util/mp4info.cpp:77 #13 0x7f341d7a0f29 in __libc_start_main (/lib64/libc.so.6+0x20f29) SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libmp4v2.so.2+0x21b26d) Shadow bytes around the buggy address: 0x0fe703517ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe703517eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe703517ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe703517ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe703517ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0fe703517ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa 0x0fe703517f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe703517f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe703517f20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe703517f30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe703517f40: 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 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 ==280==ABORTING
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.