CVE Request: ffmpeg remote exploitaion results code execution

[Paul Cher <paulcher () seclab cs msu su>]

This letter is a result of research made by Emil Lerner <neex.emil () gmail com <mailto:neex.emil () gmail com>> and 
Pavel Cheremushkin <paulcher () seclab cs msu su <mailto:paulcher () seclab cs msu su>> and it is supposed to disclosed 
multiple issues we managed to find and exploit in FFmpeg software. Despite that all vulnerabilities have been 
successfully patched by FFmpeg developers this letter is supposed to clarify all these issues and show that they are 
exploitable.

--[ 1 - libavformat/http.c  ]

After executing of http_read_stream we read each http header, where we pass "Transfer-Encoding: chunked” header, and we 
come into http_buf_read function [1]. Due to incorrect use of strtoll function and integer sizes (chunk_size in 
int64_t)[2], it was possible to pass negative chunk_size in chunk encoding, so after computing final size using FFMIN 
function later on it would be passed as argument to avio_read function. This results a heap-overflow which we found out 
to be exploitable, because overflowed buffer is allocated right next to the AVIOContext structure[3]. Overflowing 
function pointer in this structure immediately results rip control and then code execution.

* [1] - https://github.com/FFmpeg/FFmpeg/blob/51020adcecf4004c1586a708d96acc6cbddd050a/libavformat/http.c#L1166 
<https://github.com/FFmpeg/FFmpeg/blob/51020adcecf4004c1586a708d96acc6cbddd050a/libavformat/http.c#L1166>
* [2] - https://github.com/FFmpeg/FFmpeg/blob/51020adcecf4004c1586a708d96acc6cbddd050a/libavformat/http.c#L1259 
<https://github.com/FFmpeg/FFmpeg/blob/51020adcecf4004c1586a708d96acc6cbddd050a/libavformat/http.c#L1259>
* [3] - https://github.com/FFmpeg/FFmpeg/blob/51020adcecf4004c1586a708d96acc6cbddd050a/libavformat/aviobuf.c#L899 
<https://github.com/FFmpeg/FFmpeg/blob/51020adcecf4004c1586a708d96acc6cbddd050a/libavformat/aviobuf.c#L899>

This issue was fixed in https://github.com/FFmpeg/FFmpeg/commit/2a05c8f813de6f2278827734bf8102291e7484aa 
<https://github.com/FFmpeg/FFmpeg/commit/2a05c8f813de6f2278827734bf8102291e7484aa>

--[ 2 - libavformat/rtmppkt.c ]

Issue is connected with buffer overflow on the heap in RTMP protocol. After a bit of reverse engineering of RTMP 
protocol you can notice that it uses chunk (of max 0x80 bytes) to _transfer_ data, but chunks of more size could be 
used to _store_ the data. Because size of packet is not check that it is the same as it was in the same transmission 
you can first send packet with smaller size and then bigger size, and this results heap-overflow[1]. If you can align 
chunks right you can achieve white-what-where condition and that results and RCE.

* [1] - https://github.com/FFmpeg/FFmpeg/blob/d903b4e3ad4a81b3dd79f12c2f3b9cb16e511173/libavformat/rtmppkt.c#L268 
<https://github.com/FFmpeg/FFmpeg/blob/d903b4e3ad4a81b3dd79f12c2f3b9cb16e511173/libavformat/rtmppkt.c#L268>

The issue was fixed in https://github.com/FFmpeg/FFmpeg/commit/7d57ca4d9a75562fa32e40766211de150f8b3ee7 
<https://github.com/FFmpeg/FFmpeg/commit/7d57ca4d9a75562fa32e40766211de150f8b3ee7>

--[ 3 - ffserver.c ]

This issue is completely like the first one and it results heap overflow.

This issue was fixed in https://github.com/FFmpeg/FFmpeg/commit/a5d25faa3f4b18dac737fdb35d0dd68eb0dc2156 
<https://github.com/FFmpeg/FFmpeg/commit/a5d25faa3f4b18dac737fdb35d0dd68eb0dc2156>

--[ Conclusion ]

We are currently continue our research on FFmpeg security and hope to contribute more later on. These issues where 
fixed quite long ago, so I find it acceptable to attach links to exploits:
* https://gist.github.com/PaulCher/324690b88db8c4cf844e056289d4a1d6 
<https://gist.github.com/PaulCher/324690b88db8c4cf844e056289d4a1d6>
* https://gist.github.com/PaulCher/9acf4dc47c95a8b40b456ba03b05a913 
<https://gist.github.com/PaulCher/9acf4dc47c95a8b40b456ba03b05a913>

Thanks in advance,
Paul