openSUSE Security Update : ffmpeg / ffmpeg2 (openSUSE-2017-1067)

This script is Copyright (C) 2017 Tenable Network Security, Inc.


Synopsis :

The remote openSUSE host is missing a security update.

Description :

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

See also :

https://bugzilla.opensuse.org/show_bug.cgi?id=1015120
https://bugzilla.opensuse.org/show_bug.cgi?id=1022920
https://bugzilla.opensuse.org/show_bug.cgi?id=1022921
https://bugzilla.opensuse.org/show_bug.cgi?id=1022922
https://bugzilla.opensuse.org/show_bug.cgi?id=1034176
https://bugzilla.opensuse.org/show_bug.cgi?id=1034177
https://bugzilla.opensuse.org/show_bug.cgi?id=1034179
https://bugzilla.opensuse.org/show_bug.cgi?id=1046211
https://bugzilla.opensuse.org/show_bug.cgi?id=1049095
https://bugzilla.opensuse.org/show_bug.cgi?id=1056760
https://bugzilla.opensuse.org/show_bug.cgi?id=1056761
https://bugzilla.opensuse.org/show_bug.cgi?id=1056762
https://bugzilla.opensuse.org/show_bug.cgi?id=1056763
https://bugzilla.opensuse.org/show_bug.cgi?id=1056765
https://bugzilla.opensuse.org/show_bug.cgi?id=1056766
https://bugzilla.opensuse.org/show_bug.cgi?id=1057536
https://bugzilla.opensuse.org/show_bug.cgi?id=1057537
https://bugzilla.opensuse.org/show_bug.cgi?id=1057539
https://bugzilla.opensuse.org/show_bug.cgi?id=1058018
https://bugzilla.opensuse.org/show_bug.cgi?id=1058019
https://bugzilla.opensuse.org/show_bug.cgi?id=1058020

Solution :

Update the affected ffmpeg / ffmpeg2 packages.

Risk factor :

High / CVSS Base Score : 7.5
(CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P)

Ready to Amp Up Your Nessus Experience?

Get Nessus Professional to scan unlimited IPs, run compliance checks & more

Buy Nessus Professional Now