[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jan 2015 15:58:22 -0500 (EST)
From: cve-assign@...re.org
To: fabian.yamaguchi@...uni-goettingen.de
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Vulnerabilities in VLC 2.1.5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> * Buffer overflow in updater:
>
> https://github.com/videolan/vlc/commit/fbe2837bc80f155c001781041a54c58b5524fc14
Use CVE-2014-9625 for this integer truncation caused by a cast to
size_t (with resultant buffer overflow).
> * Buffer overflow in mp4 demuxer:
>
> https://github.com/videolan/vlc/commit/2e7c7091a61aa5d07e7997b393d821e91f593c39
In 2e7c7091a61aa5d07e7997b393d821e91f593c39, the vendor discusses
"avoid an integer underflow" and "make sure no truncation occurs."
These are closely related to the original "If set to 7, the argument
passed to malloc at (1) is 0" report, but the vendor has explicitly
mentioned other attacks that were not directly covered in your
"Original Bug Reports" section.
Use CVE-2014-9626 for the integer underflow.
Use CVE-2014-9627 for the integer truncation on 32-bit platforms.
Use CVE-2014-9628 for the attacker-triggered zero-size malloc with
resultant buffer overflow.
> * Potential buffer overflow in Schroedinger Encoder
>
> https://github.com/videolan/vlc/commit/9bb0353a5c63a7f8c6fc853faa3df4b4df1f5eb5
Use CVE-2014-9629 for this integer overflow with resultant buffer
overflow.
> The function Encode in modules/codec/dirac.c
>
> The same code can be found in function Encode in
> modules/codec/schroedinger.c.
>
> * The potential buffer overflow in the Dirac Encoder was not fixed as
> the Dirac encoder no longer exists in the master branch.
The dirac.c and schroedinger.c issues have the same CVE ID because it
is exactly the same problem in an identical block of code. (In other
words, the code was copied from one to the other; there were not two
separate implementation errors.)
> * Invalid memory access in rtp code:
>
> https://github.com/videolan/vlc/commit/204291467724867b79735c0ee3aeb0dbc2200f97
Use CVE-2014-9630 for this stack allocation with an
attacker-controlled size.
> modules/services_discovery/sap.c:
> static sdp_t *ParseSDP
>
> char line[linelen + 1];
Use CVE-2015-1202 for this stack allocation with an
attacker-controlled size (we did not confirm this, but it appears that
the attacker would send an SAP multicast).
(
> The potential invalid writes in modules/services_discovery/sap.c and
> modules/access/ftp.c were not fixed
This is in contrast to the fixed rtp issue, in which an upcoming VLC
version would not be affected.
https://github.com/videolan/vlc/blob/master/modules/services_discovery/sap.c
suggests that this code is from 2004, which would mean that it affects
fewer old versions than -- for example -- ftp.c, which is a few years
older.
)
> modules/access/ftp.c:
> static int ftp_SendCommand
>
> char fmtbuf[fmtlen + 3];
Use CVE-2015-1203 for this stack allocation with an
attacker-controlled size (we did not confirm this, but it appears that
the attacker would operate an FTP server that includes long filenames
in an NLST response, and the victim would choose one of those files).
> We also found the following minor issues that we believe can at most
> result in a null-pointer dereference and thus, a crash. For the sake
> of completeness, we report them as well.
>
> The allocations at (1)-(6) in the function TrackCreateES in
> /modules/demux/mp4/mp4.c are not checked, possibly resulting in
> subsequent null-pointer dereferences when calling memcpy in the
> respective next line.
>
> In function EncoderSetAudioType in modules/codec/dmo/dmo.c, the
> allocation at (1) is not checked, possibly resulting a null-pointer
> dereference in the subsequent call to memcpy.
>
> * Null-pointer dereference in dmo codec:
>
> https://github.com/videolan/vlc/commit/229c385a79d48e41687fae8b4dfeaeef9c8c3eb7
There are currently no CVE IDs for these NULL pointer dereference
issues. Our understanding is that the common VLC use cases don't have
multiple sessions where the user is potentially working with valid
input and malicious input at exactly the same time. Accordingly, a
user can avoid the main impact by not accessing the malicious input
again. (Admittedly, there might be minor "data loss" if an unsaved
playlist is lost when VLC crashes, but we're not sure that a common
use case is to work with an unsaved playlist that is very difficult to
regenerate.)
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJUvsDRAAoJEKllVAevmvmsypcH+gLsqMd+mr3+CJ9uE2olSTFa
dcr3lj37Yc9bq0tmBeKueraC5vhtIck1efQQGoKVQoyUY8e+PuASYEUVSFmt3GTl
U0bSOWYaONRaLto0tlwNBsQpcFwdDWR4vq1CvTu4xrVTK4O9TjegPRUX83Mkwgfa
6upoPwgjRnKbw9SEmJid7JYrTUqgDu7qBrVeogCSw+8mDR164tN7D1p8A2SAXZHI
cjhlfrcTLN9wNHOiC4xsZU6cm7Fsjj09nEe9lAJAQ+2iAugnNRwU/+b49Ru7urPy
hMKz9oSrPsuiZFWktVFfFQHSvJRLbJhwFQuY7T139mSmxLxZdD3igwEbsPtSfiM=
=uUG2
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
