Hi Diego,
I've had a look at CVE-2015-8218 and couldn't reproduce it with the
sample. After further investigations it's pretty clear to me that
libav v0.8.21 and libav v9.21 aren't affected.
Further explanations below.
--
The issue described by CVE-2015-8218 occurs in the decode_uncompressed
function (CCIT Fax decoder).
This function (present since b2e95e012c3c857eb1f8fddc7a41c0c4f0581f30
in ffmpeg and absent from libav 0.8.21/9.21) decodes uncompressed Group-3
encoded data.
decode_uncompressed is called at two places in ffmpeg's source code:
1) In the Group 3 One-Dimensional (G31D) decoder
ffmpeg's G31D decoder has support for uncompressed mode (see page 12, T.4
of the Group-3 standard[0]) so whenever it meets a non-standard code word
(get_vlc2 returns -1) it also checks for 000000001xxx (special code word
for extensions) with xxx=111 (=15). If it's the case, decode_uncompressed
is used to retrieve the uncompressed data.
This feature is present in ffmpeg since a4f9bb228bb34f0cfa4b55b207c19604b1e36818.
libav's G31D decoder (v0.8.21/v9.21) doesn't support extension codes at all,
so we can safely consider it as unaffected by the issue.
2) In the Group 3 Two-Dimensional (G32D) decoder.
ffmpeg's G32D decoder has support for code extensions, and in particular
uncompressed mode. So whenever it meets the 2-D extension code 0000001xxx
with xxx=111, it uses the decode_uncompressed function to retrieve the
uncompressed data.
This feature is present in ffmpeg since 38025e6898ef7caa076ff20daf4fc9f27269e4df.
Just like G31D, libav's G32D decoder (v0.8.21 & v9.21) doesn't support
extension codes at all, so we can safely consider it as unaffected by the
issue.
Short: CVE-2015-8218 is affecting a feature that is not present in libav.
Regards,
Hugo
[0] http://www.itu.int/rec/T-REC-T.4-200307-I/en
--
Hugo Lefeuvre (hle) | www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
Attachment:
signature.asc
Description: PGP signature