[vlc-devel] [PATCH] win32: do not load wininet.dll on startup, it's not a Known DLL

Jean-Baptiste Kempf jb at videolan.org
Wed Mar 29 22:48:09 CEST 2017


Hello,

On Wed, 29 Mar 2017, at 22:25, Rémi Denis-Courmont wrote:
> > I disagree.
> 
> I don´t see what there is to agree or disagree with, except alternative
> facts here.

Calling me a liar is not going to work fine with me. Not at all.

I'm quite nice, and I've accepted quite a few things lately, on this
very mailing-list, but don't push me.

> The only difference this makes is whether a DLL in the installation
> directory 
> can replace the Windows DLL. This is a _not_ a VLC security issue.
> 
> If the user actually put a DLL in the installation directory, s/he wants
> to use VLC with it. You just made that never used feature impossible.

There is no reason to load any DLL from the VLC installation directory
beside libvlccore|libvlc and VLC plugins.
Especially system DLLs. We're not on Linux.

We load only from SYSTEM32 in loadlibrary calls, then we should do the
same in implib.
Or we do none of those.

> This patch is totally wrong. Indeed, two weeks on, nobody has been able
> to  provide a threat model that would make this a security vulnerability.

You forget people using VLC as portable version.

> Anybody who would hypothetically claim that this is a VLC security issue
> is either clueless or lying.

It's not stricto-sensu a strong security issue, since only a
non-installed version can be compromised, or the person has UAC control.
But after those patches, you need SYSTEM control to exploit it.

And yes, there is still the issue of VLC plugins loading, and that needs
a solution.

Also, it's a good idea to fix all the scenarios, including portable
versions, seeing the number of users.



-- 
Jean-Baptiste Kempf -  President
+33 672 704 734


More information about the vlc-devel mailing list