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

[Rémi Denis-Courmont]

Le keskiviikkona 29. maaliskuuta 2017, 22.48.09 EEST Jean-Baptiste Kempf a 
écrit :
> > 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. 
https://blogs.msdn.microsoft.com/oldnewthing/20070807-00/?p=25683/
(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 
impossible.)

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 
reverted.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/