In the mxf_read_primer_pack function in libavformat/mxfdec.c in FFmpeg 3.3.3 -> 2.4, an integer signedness error might occur when a crafted file, which claims a large "item_num" field such as 0xffffffff, is provided. As a result, the variable "item_num" turns negative, bypassing the check for a large value.

Several security issues have been corrected in multiple demuxers and decoders of the libav multimedia library.

CVE-2014-8542

libavcodec/utils.c omitted a certain codec ID during enforcement of alignment, which allowed remote attackers to cause a denial of ervice (out-of-bounds access) or possibly have unspecified other impact via crafted JV data.

CVE-2015-1207

Double-free vulnerability in libavformat/mov.c allowed remote attackers to cause a denial of service (memory corruption and crash) via a crafted .m4a file.

CVE-2017-7863

libav had an out-of-bounds write caused by a heap-based buffer overflow related to the decode_frame_common function in libavcodec/pngdec.c.

CVE-2017-7865

libav had an out-of-bounds write caused by a heap-based buffer overflow related to the ipvideo_decode_block_opcode_0xA function in libavcodec/interplayvideo.c and the avcodec_align_dimensions2 function in libavcodec/utils.c.

CVE-2017-14169

In the mxf_read_primer_pack function in libavformat/mxfdec.c in, an integer signedness error might have occured when a crafted file, claiming a large 'item_num' field such as 0xffffffff, was provided. As a result, the variable 'item_num' turned negative, bypassing the check for a large value.

CVE-2017-14223

In libavformat/asfdec_f.c a DoS in asf_build_simple_index() due to lack of an EOF (End of File) check might have caused huge CPU consumption. When a crafted ASF file, claiming a large 'ict' field in the header but not containing sufficient backing data, was provided, the for loop would have consumed huge CPU and memory resources, since there was no EOF check inside the loop.

For Debian 8 'Jessie', these problems have been fixed in version 6:11.12-1~deb8u5.

We recommend that you upgrade your libav packages.

NOTE: Tenable Network Security has extracted the preceding description block directly from the DLA security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

FFmpeg security reports :

Multiple vulnerabilities have been fixed in FFmpeg 3.3.4. Please refer to the CVE list for details.

Several vulnerabilities have been discovered in the FFmpeg multimedia framework, which could result in denial of service or potentially the execution of arbitrary code if malformed Real, MV, RL2, ASF, Apple HLS, Phantom Cine, MXF, NSV, MOV or RTP H.264 files/streams are processed.

This update introduces lame and twolame.

For ffmpeg2 it updates to version 2.8.13 and fixes several issues.

These security issues were fixed :

  - CVE-2017-14058: The read_data function in     libavformat/hls.c did not restrict reload attempts for     an insufficient list, which allowed remote attackers to     cause a denial of service (infinite loop) (bsc#1056762)

  - CVE-2017-14057: In asf_read_marker() due to lack of an     EOF (End of File) check might have caused huge CPU and     memory consumption. When a crafted ASF file, which     claims a large 'name_len' or 'count' field in the header     but did not contain sufficient backing data, was     provided, the loops over the name and markers would     consume huge CPU and memory resources, since there is no     EOF check inside these loops (bsc#1056761)

  - CVE-2017-14059: A DoS in cine_read_header() due to lack     of an EOF check might have caused huge CPU and memory     consumption. When a crafted CINE file, which claims a     large 'duration' field in the header but did not contain     sufficient backing data, was provided, the image-offset     parsing loop would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056763)

  - CVE-2017-14056: A DoS in rl2_read_header() due to lack     of an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted RL2 file, which     claims a large 'frame_count' field in the header but did     not contain sufficient backing data, was provided, the     loops (for offset and size tables) would consume huge     CPU and memory resources, since there is no EOF check     inside these loops (bsc#1056760)

  - CVE-2017-14055: a DoS in mv_read_header() due to lack of     an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted MV file, which     claims a large 'nb_frames' field in the header but did     not contain sufficient backing data, was provided, the     loop over the frames would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056766)

  - boo#1046211: Lots of integer overflow fixes

  - CVE-2017-14169: In the mxf_read_primer_pack function an     integer signedness error have might occured when a     crafted file, which claims a large 'item_num' field such     as 0xffffffff, was provided. As a result, the variable     'item_num' turns negative, bypassing the check for a     large value (bsc#1057536)

  - CVE-2017-14170: Prevent DoS in     mxf_read_index_entry_array() due to lack of an EOF (End     of File) check that might have caused huge CPU     consumption. When a crafted MXF file, which claims a     large 'nb_index_entries' field in the header but did not     contain sufficient backing data, was provided, the loop     would consume huge CPU resources, since there was no EOF     check inside the loop. Moreover, this big loop can be     invoked multiple times if there is more than one     applicable data segment in the crafted MXF file     (bsc#1057537)

  - CVE-2017-14171: Prevent DoS in nsv_parse_NSVf_header()     due to lack of an EOF (End of File) check taht might     have caused huge CPU consumption. When a crafted NSV     file, which claims a large 'table_entries_used' field in     the header but did not contain sufficient backing data,     was provided, the loop over 'table_entries_used' would     consume huge CPU resources, since there was no EOF check     inside the loop (bsc#1057539)

  - !: CVE-2017-14223: Prevent DoS in     asf_build_simple_index() due to lack of an EOF (End of     File) check that might have caused huge CPU consumption.
    When a crafted ASF file, which claims a large 'ict'     field in the header but did not contain sufficient     backing data, was provided, the for loop would consume     huge CPU and memory resources, since there was no EOF     check inside the loop (bsc#1058019)

  - !: CVE-2017-14222: Prevent DoS in read_tfra() due to     lack of an EOF (End of File) check that might have     caused huge CPU and memory consumption. When a crafted     MOV file, which claims a large 'item_count' field in the     header but did not contain sufficient backing data, was     provided, the loop would consume huge CPU and memory     resources, since there was no EOF check inside the loop     (bsc#1058020)

These non-security issues were fixed :

  - Unconditionalize celt, ass, openjpeg, webp, libva,     vdpau.

  - Build unconditionally with lame and twolame

For ffmpeg it updates to version 3.3.4 and fixes several issues.

These security issues were fixed :

  - CVE-2017-14058: The read_data function in     libavformat/hls.c did not restrict reload attempts for     an insufficient list, which allowed remote attackers to     cause a denial of service (infinite loop) (bsc#1056762)

  - CVE-2017-14057: In asf_read_marker() due to lack of an     EOF (End of File) check might have caused huge CPU and     memory consumption. When a crafted ASF file, which     claims a large 'name_len' or 'count' field in the header     but did not contain sufficient backing data, was     provided, the loops over the name and markers would     consume huge CPU and memory resources, since there is no     EOF check inside these loops (bsc#1056761)

  - CVE-2017-14059: A DoS in cine_read_header() due to lack     of an EOF check might have caused huge CPU and memory     consumption. When a crafted CINE file, which claims a     large 'duration' field in the header but did not contain     sufficient backing data, was provided, the image-offset     parsing loop would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056763)

  - CVE-2017-14054: A DoS in ivr_read_header() due to lack     of an EOF (End of File) check might have caused huge CPU     consumption. When a crafted IVR file, which claims a     large 'len' field in the header but did not contain     sufficient backing data, was provided, the first type==4     loop would consume huge CPU resources, since there is no     EOF check inside the loop (bsc#1056765)

  - CVE-2017-14056: A DoS in rl2_read_header() due to lack     of an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted RL2 file, which     claims a large 'frame_count' field in the header but did     not contain sufficient backing data, was provided, the     loops (for offset and size tables) would consume huge     CPU and memory resources, since there is no EOF check     inside these loops (bsc#1056760)

  - CVE-2017-14055: a DoS in mv_read_header() due to lack of     an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted MV file, which     claims a large 'nb_frames' field in the header but did     not contain sufficient backing data, was provided, the     loop over the frames would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056766)

  - CVE-2017-11399: Integer overflow in the ape_decode_frame     function allowed remote attackers to cause a denial of     service (out-of-array access and application crash) or     possibly have unspecified other impact via a crafted APE     file (bsc#1049095)

  - CVE-2017-14171: Prevent DoS in nsv_parse_NSVf_header()     due to lack of an EOF (End of File) check taht might     have caused huge CPU consumption. When a crafted NSV     file, which claims a large 'table_entries_used' field in     the header but did not contain sufficient backing data,     was provided, the loop over 'table_entries_used' would     consume huge CPU resources, since there was no EOF check     inside the loop (bsc#1057539)

  - CVE-2017-14170: Prevent DoS in     mxf_read_index_entry_array() due to lack of an EOF (End     of File) check that might have caused huge CPU     consumption. When a crafted MXF file, which claims a     large 'nb_index_entries' field in the header but did not     contain sufficient backing data, was provided, the loop     would consume huge CPU resources, since there was no EOF     check inside the loop. Moreover, this big loop can be     invoked multiple times if there is more than one     applicable data segment in the crafted MXF file     (bsc#1057537)

  - CVE-2017-14169: In the mxf_read_primer_pack function an     integer signedness error have might occured when a     crafted file, which claims a large 'item_num' field such     as 0xffffffff, was provided. As a result, the variable     'item_num' turns negative, bypassing the check for a     large value (bsc#1057536)

  - CVE-2017-14225: The av_color_primaries_name function may     have returned a NULL pointer depending on a value     contained in a file, but callers did not anticipate     this, leading to a NULL pointer dereference     (bsc#1058018)

  - CVE-2017-14223: Prevent DoS in asf_build_simple_index()     due to lack of an EOF (End of File) check that might     have caused huge CPU consumption. When a crafted ASF     file, which claims a large 'ict' field in the header but     did not contain sufficient backing data, was provided,     the for loop would consume huge CPU and memory     resources, since there was no EOF check inside the loop     (bsc#1058019)

  - CVE-2017-14222: Prevent DoS in read_tfra() due to lack     of an EOF (End of File) check that might have caused     huge CPU and memory consumption. When a crafted MOV     file, which claims a large 'item_count' field in the     header but did not contain sufficient backing data, was     provided, the loop would consume huge CPU and memory     resources, since there was no EOF check inside the loop     (bsc#1058020)

It also includes various fixes for integer overflows and too-large bit shifts that didn't receive a CVE.

These non-security issues were fixed :

  - Unconditionalize celt, ass, openjpeg, webp, netcdf,     libva, vdpau.

  - Build unconditionally with lame and twolame

  - boo#1041794: Disable cuda extensions

  - Add additional checks to ensure MPEG is off

This update introduces lame and twolame. For ffmpeg2 it updates to version 2.8.13 and fixes several issues.

These security issues were fixed :

  - CVE-2017-14058: The read_data function in     libavformat/hls.c did not restrict reload attempts for     an insufficient list, which allowed remote attackers to     cause a denial of service (infinite loop) (bsc#1056762).

  - CVE-2017-14057: In asf_read_marker() due to lack of an     EOF (End of File) check might have caused huge CPU and     memory consumption. When a crafted ASF file, which     claims a large 'name_len' or 'count' field in the header     but did not contain sufficient backing data, was     provided, the loops over the name and markers would     consume huge CPU and memory resources, since there is no     EOF check inside these loops (bsc#1056761).

  - CVE-2017-14059: A DoS in cine_read_header() due to lack     of an EOF check might have caused huge CPU and memory     consumption. When a crafted CINE file, which claims a     large 'duration' field in the header but did not contain     sufficient backing data, was provided, the image-offset     parsing loop would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056763).

  - CVE-2017-14056: A DoS in rl2_read_header() due to lack     of an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted RL2 file, which     claims a large 'frame_count' field in the header but did     not contain sufficient backing data, was provided, the     loops (for offset and size tables) would consume huge     CPU and memory resources, since there is no EOF check     inside these loops (bsc#1056760).

  - CVE-2017-14055: a DoS in mv_read_header() due to lack of     an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted MV file, which     claims a large 'nb_frames' field in the header but did     not contain sufficient backing data, was provided, the     loop over the frames would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056766).

  - boo#1046211: Lots of integer overflow fixes

  - CVE-2016-9561: The che_configure function in     libavcodec/aacdec_template.c in FFmpeg allowed remote     attackers to cause a denial of service (allocation of     huge memory, and being killed by the OS) via a crafted     MOV file (boo#1015120)

  - CVE-2017-7863: FFmpeg had an out-of-bounds write caused     by a heap-based buffer overflow related to the     decode_frame_common function in libavcodec/pngdec.c     (boo#1034179)

  - CVE-2017-7865: FFmpeg had an out-of-bounds write caused     by a heap-based buffer overflow related to the     ipvideo_decode_block_opcode_0xA function in     libavcodec/interplayvideo.c and the     avcodec_align_dimensions2 function in libavcodec/utils.c     (boo#1034177)

  - CVE-2017-7866: FFmpeg had an out-of-bounds write caused     by a stack-based buffer overflow related to the     decode_zbuf function in libavcodec/pngdec.c     (boo#1034176)

  - CVE-2016-10190: Heap-based buffer overflow in     libavformat/http.c in FFmpeg allowed remote web servers     to execute arbitrary code via a negative chunk size in     an HTTP response (boo#1022920)

  - CVE-2016-10191: Heap-based buffer overflow in     libavformat/rtmppkt.c in FFmpeg allowed remote attackers     to execute arbitrary code by leveraging failure to check     for RTMP packet size mismatches (boo#1022921)

  - CVE-2016-10192: Heap-based buffer overflow in ffserver.c     in FFmpeg allowed remote attackers to execute arbitrary     code by leveraging failure to check chunk size     (boo#1022922)

  - CVE-2017-14169: In the mxf_read_primer_pack function an     integer signedness error have might occured when a     crafted file, which claims a large 'item_num' field such     as 0xffffffff, was provided. As a result, the variable     'item_num' turns negative, bypassing the check for a     large value (bsc#1057536).

  - CVE-2017-14170: Prevent DoS in     mxf_read_index_entry_array() due to lack of an EOF (End     of File) check that might have caused huge CPU     consumption. When a crafted MXF file, which claims a     large 'nb_index_entries' field in the header but did not     contain sufficient backing data, was provided, the loop     would consume huge CPU resources, since there was no EOF     check inside the loop. Moreover, this big loop can be     invoked multiple times if there is more than one     applicable data segment in the crafted MXF file     (bsc#1057537).

  - CVE-2017-14171: Prevent DoS in nsv_parse_NSVf_header()     due to lack of an EOF (End of File) check taht might     have caused huge CPU consumption. When a crafted NSV     file, which claims a large 'table_entries_used' field in     the header but did not contain sufficient backing data,     was provided, the loop over 'table_entries_used' would     consume huge CPU resources, since there was no EOF check     inside the loop (bsc#1057539).

  - CVE-2017-14223: Prevent DoS in asf_build_simple_index()     due to lack of an EOF (End of File) check that might     have caused huge CPU consumption. When a crafted ASF     file, which claims a large 'ict' field in the header but     did not contain sufficient backing data, was provided,     the for loop would consume huge CPU and memory     resources, since there was no EOF check inside the loop     (bsc#1058019)

  - CVE-2017-14222: Prevent DoS in read_tfra() due to lack     of an EOF (End of File) check that might have caused     huge CPU and memory consumption. When a crafted MOV     file, which claims a large 'item_count' field in the     header but did not contain sufficient backing data, was     provided, the loop would consume huge CPU and memory     resources, since there was no EOF check inside the loop     (bsc#1058020)

These non-security issues were fixed :

  - Unconditionalize celt, ass, openjpeg, webp, libva,     vdpau.

  - Build unconditionally with lame and twolame

  - Enable AC3 and MP3 decoding to match     multimedia:libs/ffmpeg (3.x)

For ffmpeg it updates to version 3.3.4 and fixes several issues.

These security issues were fixed :

  - CVE-2017-14225: The av_color_primaries_name function may     have returned a NULL pointer depending on a value     contained in a file, but callers did not anticipate     this, leading to a NULL pointer dereference     (bsc#1058018).

  - CVE-2017-14223: Prevent DoS in asf_build_simple_index()     due to lack of an EOF (End of File) check that might     have caused huge CPU consumption. When a crafted ASF     file, which claims a large 'ict' field in the header but     did not contain sufficient backing data, was provided,     the for loop would consume huge CPU and memory     resources, since there was no EOF check inside the loop     (bsc#1058019).

  - CVE-2017-14222: Prevent DoS in read_tfra() due to lack     of an EOF (End of File) check that might have caused     huge CPU and memory consumption. When a crafted MOV     file, which claims a large 'item_count' field in the     header but did not contain sufficient backing data, was     provided, the loop would consume huge CPU and memory     resources, since there was no EOF check inside the loop     (bsc#1058020).

  - CVE-2017-14058: The read_data function in     libavformat/hls.c did not restrict reload attempts for     an insufficient list, which allowed remote attackers to     cause a denial of service (infinite loop) (bsc#1056762)

  - CVE-2017-14057: In asf_read_marker() due to lack of an     EOF (End of File) check might have caused huge CPU and     memory consumption. When a crafted ASF file, which     claims a large 'name_len' or 'count' field in the header     but did not contain sufficient backing data, was     provided, the loops over the name and markers would     consume huge CPU and memory resources, since there is no     EOF check inside these loops (bsc#1056761)

  - CVE-2017-14059: A DoS in cine_read_header() due to lack     of an EOF check might have caused huge CPU and memory     consumption. When a crafted CINE file, which claims a     large 'duration' field in the header but did not contain     sufficient backing data, was provided, the image-offset     parsing loop would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056763)

  - CVE-2017-14054: A DoS in ivr_read_header() due to lack     of an EOF (End of File) check might have caused huge CPU     consumption. When a crafted IVR file, which claims a     large 'len' field in the header but did not contain     sufficient backing data, was provided, the first type==4     loop would consume huge CPU resources, since there is no     EOF check inside the loop (bsc#1056765).

  - CVE-2017-14056: A DoS in rl2_read_header() due to lack     of an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted RL2 file, which     claims a large 'frame_count' field in the header but did     not contain sufficient backing data, was provided, the     loops (for offset and size tables) would consume huge     CPU and memory resources, since there is no EOF check     inside these loops (bsc#1056760)

  - CVE-2017-14055: a DoS in mv_read_header() due to lack of     an EOF (End of File) check might have caused huge CPU     and memory consumption. When a crafted MV file, which     claims a large 'nb_frames' field in the header but did     not contain sufficient backing data, was provided, the     loop over the frames would consume huge CPU and memory     resources, since there is no EOF check inside the loop     (bsc#1056766)

  - CVE-2017-11399: Integer overflow in the ape_decode_frame     function allowed remote attackers to cause a denial of     service (out-of-array access and application crash) or     possibly have unspecified other impact via a crafted APE     file (bsc#1049095).

  - CVE-2017-14171: Prevent DoS in nsv_parse_NSVf_header()     due to lack of an EOF (End of File) check taht might     have caused huge CPU consumption. When a crafted NSV     file, which claims a large 'table_entries_used' field in     the header but did not contain sufficient backing data,     was provided, the loop over 'table_entries_used' would     consume huge CPU resources, since there was no EOF check     inside the loop (bsc#1057539)

  - CVE-2017-14170: Prevent DoS in     mxf_read_index_entry_array() due to lack of an EOF (End     of File) check that might have caused huge CPU     consumption. When a crafted MXF file, which claims a     large 'nb_index_entries' field in the header but did not     contain sufficient backing data, was provided, the loop     would consume huge CPU resources, since there was no EOF     check inside the loop. Moreover, this big loop can be     invoked multiple times if there is more than one     applicable data segment in the crafted MXF file     (bsc#1057537)

  - CVE-2017-14169: In the mxf_read_primer_pack function an     integer signedness error have might occured when a     crafted file, which claims a large 'item_num' field such     as 0xffffffff, was provided. As a result, the variable     'item_num' turns negative, bypassing the check for a     large value (bsc#1057536)

It also includes various fixes for integer overflows and too-large bit shifts that didn't receive a CVE.

These non-security issues were fixed :

  - Unconditionalize celt, ass, openjpeg, webp, netcdf,     libva, vdpau.

  - Build unconditionally with lame and twolame

  - Enabled cuda and cuvid for unrestricted build.

  - Add additional checks to ensure MPEG is off

ID	Name	Product	Family	Severity
121622	Debian DLA-1654-1 : libav security update	Nessus	Debian Local Security Checks	critical
103844	FreeBSD : FFmpeg -- multiple vulnerabilities (ed73829d-af6d-11e7-a633-009c02a2ab30)	Nessus	FreeBSD Local Security Checks	high
103758	Debian DSA-3996-1 : ffmpeg - security update	Nessus	Debian Local Security Checks	high
103290	openSUSE Security Update : ffmpeg / ffmpeg2 (openSUSE-2017-1068)	Nessus	SuSE Local Security Checks	high
103289	openSUSE Security Update : ffmpeg / ffmpeg2 (openSUSE-2017-1067)	Nessus	SuSE Local Security Checks	critical

Detections

Analytics

CVE-2017-14169

high

Tenable Plugins

critical

high

high

high

critical