[vlc-devel] [PATCH 00/13] Execute medialib queries out of the UI thread

[Alexandre Janniaux]

Hi,

On Mon, Nov 30, 2020 at 04:30:55AM +0100, Pierre Ynard via vlc-devel wrote:
> > > Well my experience is that, if I enable the media library, VLC
> > > crashes immediately because of some demuxer bug. This is totally
> > > unacceptable.
> > >
> > > The root cause bug is most likely in an underlying library (and
> > > possibly failure of Debian to update), caused by a file in one of
> > > the standard media directory. Still, for the sake of reliability, it
> > > is totally insane and unacceptable that VLC crashes just because of
> > > a bug in a demuxer triggered by a file that is neither being played
> > > and in a directory that was not explicitly added.
> > >
> > > If this hits one out of a dozen of devs, how many million users will
> > > have VLC crash straight away?
> >
> > As you know, this is correctly tracked as #25119 whereas this
> > patchset tackles #22687. From my experience, this helped
> > highlighting a lot of issues in the code with sanitizers, like
> > prefetch so it at least served a better purpose for the user,
> > and we probably need to have a good report system (at least for
> > developers) if moved to a dedicated process. This should be
> > discussed on the #25119 though, as it's out of scope here.
>
> Wow you guys are a bit scary. I'm glad that you mention the opportunity
> to sanitize code, but I can't help but react on the security concerns
> of this. That kind of feature is a staple of remote exploit or worm
> scenarios: first desktop UX developers come up with a streamlined
> vision, then the web browser or some other application has auto-download
> or auto-saving of files, then a media component (VLC here) has
> auto-indexing with preparsing, auto-thumbnailing or whatever else,
> then all you need is to inject from anywhere a file in some obscure,
> little-known and poorly maintained demux or codec format with unpatched
> vulnerabilities in that third-party library, and there you go, automated
> RCE. This is the kind of story where you get laughed at by security
> people.
>
> And using a separate process won't solve that. I sure hope there will be
> a first-run dialog message to warn and allow the user to disable this
> auto-indexing feature - is there another ticket tracking that?

We've been doing work to do fine-grained sandboxing within VLC
for two years. The issue you mention is typically what happened
to KDE and Gnome file indexing tools with Chrome and gstreamer
based parsers so it a quite well-known scenario.

But you cannot make it happen magically, especially if you need
it to be compatible with most targets and not have an impact on
the rest of the development of the project.

Having the feature is a non-issue in my opinion, what matters
will be the policy we ship when doing the 4.0 release. #25119
design is also a potential improver since we can greatly
reduce the attack surface and resource availability from here,
specifically for the indexing scenario.

But in the end, if the video is easily accessible to the end
user and they start the playback, you're led to the same kind
of security concern, minus the «automatic» attack part so lets
hope we can fix some security issues on the way.

Most likely, as long as we don't ship, the fact that it can
crash easily is more worrying than the fact it can be
exploited, in the short term, since it's annoying for both the
developer and users, whereas security issue is worrysome for
the users.

Regards,
--
Alexandre Janniaux
Videolabs

Regards,
--
Alexandre Janniaux
Videolabs