[vlc-devel] [PATCH] win32: do not load wininet.dll on startup, it's not a Known DLL
remi at remlab.net
Fri Apr 7 22:53:15 CEST 2017
Le keskiviikkona 29. maaliskuuta 2017, 22.48.09 EEST Jean-Baptiste Kempf a
> > 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.
Microsoft says the opposite:
"It is good practice to install application DLLs in the same directory that
contains the application (...). This ensures that installing the application
does not overwrite other copies of the DLL and cause other applications to
fail. Also, if you follow this good practice, other applications do not
overwrite your copy of the DLL and cause your application to fail."
> Especially system DLLs. We're not on Linux.
Yeah Windows is not on Linux. On Linux, you would be right: Linux libraries
are not normally in the application directory. On Windows, they are.
> We load only from SYSTEM32 in loadlibrary calls, then we should do the
> same in implib. Or we do none of those.
In case that the application does not trust the user, then it can only depend
on libraries whose integrity is protected by the operating system. DRM would
be one obvious scenario. But in such case, untrusted DLLs cannot be used at
all; using LoadLibrary does not solve the problem. The solution is:
- verifying known DLLs at boot (OS),
- protecting known DLLs at run-time (OS), and
- only using known DLLs (app).
> > 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.
No I don´t. The user or the system (rather the anti-malware suite) has to
ensure the authenticity of the VLC directory. Application portability
definitely does not relieve the user from that burden.
Microsoft Windows assumes that only trusted applications are executed, e.g.
(Not to blame Microsoft here; GNU/Linux makes the same assumption.)
> > 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.
No. There are intrinsic trust assumptions that VLC has to make about the run-
time environment. Any threat model that contradicts those assumptions is
literaly absurd. And then there are consequences of those assumptions, and any
threat model contradicting those is also logically absurd.
In particular, vlc.exe is trusted. That implies trust in the containing
directory, and of all its parent directories up to the (drive letter) root as
well. That means that there _cannot_ be trojaned DLLs in the vlc.exe
directory. (In other words, if there actually is a trojaned DLL there, VLC is
already operating outside the trust model from the ground up, and security is
User running random crap from a USB stick would be either a physical access /
"evil maid"-type vulnerability, or a social engineering vulnerability. Either
way, that would _not_ be a VLC vulnerability.
With that said, a VLC patch cannot fix a non-VLC or nonexistent vulnerability.
At the very best, it can mitigate one.
> And yes, there is still the issue of VLC plugins loading, and that needs
> a solution.
There exists no such issue in the first place.
We do not literally need to trust the plugins directory to trust the VLC
executable and LibVLC DLLs. But we MUST to trust the VLC directory, and there
are no benefits in not trusting the plugins subdirectory as well then.
And so this patch is misguided, misleading and useless, and it should be
More information about the vlc-devel