[vlc-devel] CVE-2009-1045 VLC 0.9.8a DoS (crash) and possibly arbitrary code execution

[Rémi Denis-Courmont]

	Hello,

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
> you:
>
>   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

Regards,

-- 
Rémi Denis-Courmont