Closed iwashiira closed 3 months ago
This input seems to cause other memory leaks, so we will continue to investigate.
The followingsize
s also need to be compared with atom.size
as well as first bug.
https://github.com/justdan96/tsMuxer/blob/75c9cb3514815d07378007d36cc90c3f209e7b36/tsMuxer/movDemuxer.cpp#L1510-L1519
this heap buffer overflow is exploitable (reverse shell can be activated).
The ASAN of mov_read_trun has not completely disappeared, but at least the heap buffer overflow has been completely mitigated by PR #851 .
Our fuzzer found heap buffer overflow in movDemuxer. in the current master(75c9cb3). PoC is here.
Following is an output of ASAN. vuln15.mov is in poc15.zip
It is caused by two Bug
mov_read_stsd()
.https://github.com/justdan96/tsMuxer/blob/75c9cb3514815d07378007d36cc90c3f209e7b36/tsMuxer/movDemuxer.cpp#L1522
a.size
is a value calculated based on user input, but it does not take min with the size of stsd, that is,atom.size - ( m_processedBytes - start_pos)
. Whena.size
is large, assuming a very large atom exists under stsd, all subsequent input would be subject toParseEntryTable
undermov_read_stsd
.ctts_count
is not initialized withentries
inmov_read_ctts
.https://github.com/justdan96/tsMuxer/blob/75c9cb3514815d07378007d36cc90c3f209e7b36/tsMuxer/movDemuxer.cpp#L1189-L1191
When calling in the order of
mov_read_trun
->mov_read_ctts
->mov_read_trun
, the vector ofctts_data
is resized inmov_read_ctts
butctts_count
remains, so a heap buffer overflow occurs at the following place in the secondmov_read_trun
.https://github.com/justdan96/tsMuxer/blob/75c9cb3514815d07378007d36cc90c3f209e7b36/tsMuxer/movDemuxer.cpp#L1100-L1102
The first bug makes it easier for the second bug to ignite.
This heap overflow has the potential to destroy the heap to some extent at will.
Ricerca Security, Inc.