[vlc-devel] CVE-2009-1045 VLC 0.9.8a DoS (crash) and possibly arbitrary code execution
rem at videolan.org
Wed Mar 25 01:05:02 CET 2009
On Wednesday 25 March 2009 01:42:58 Steven M. Christey wrote:
> I have modified CVE-2009-1045 to use the "stack consumption" term which
> CVE prefers in order to distinguish from stack-based buffer overflows.
> This was a mis-read of MILW0RM:8213 exacerbated by the researcher's use of
> the term along with the use of a long input string.
> Regarding your statement about it being a non-issue: it would be very
> useful to CVE if we could post a formally-approved comment by you, then
> reference it and flag the CVE as either "disputed" or "rejected." (This
> would be posted to the VIM list, which is monitored by all the major vuln
> DBs). The main questions here are (a) whether anybody besides the VLC
> user can access the web server and requests/status.xml,
Anybody in possession of the web interface password, and passing the ACL can
access that URL. As a side note, the web interface is not enabled by default,
and the ACL defaults to 127./8 and ::1.
> or (b) whether the
> VLC user can easily consume excessive memory on a multi-user system that
> is running VLC.
The web interface allows shutting down the player, overwriting arbitrary files
from the process user ID, overriding the plugin search path (-> arbitrary code
run at the next player start), opening a script that will DoS the process,
etc. The user account running VLC is effectively compromised if you grant
another user access to the any VLC user interface (web or otherwise).
> For the former, I assume not. For the latter, we would probably still
> consider it an issue for CVE. (If it only takes me a single request to
> kill a server, while expending very little bandwidth or CPU on my part,
> then it's an issue in CVE's book).
> Would you be comfortable if I posted the following as a statement from
> This report is incorrect. The issue is a stack overflow, a plain
> old-style stack overflow. It is _not_ a (stack-based) buffer overflow.
> The ability to run arbitrary code has not been proven, as the
> traditional buffer overflow explot techniques are _not_ applicable. But
> this is all moot because this is _not_ a _security_ issue. Users can
> only crash their own VLC instances via the (Web) user interface.
> It does not address question (b) that I laid out above, however.
> - Steve
More information about the vlc-devel