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

Jean-Baptiste Kempf jb at videolan.org
Tue Mar 14 05:22:54 CET 2017


On 14/03/2017 04:57, Pierre Ynard wrote:
> These patches sure look like snake oil to me.

Then you have no idea what you are talking about.

> To me this is akin to security through obfuscation. This is merely
> embedding and burying loading and security mechanisms into binary blobs
> and compiled machine code so they're less accessible to by-pass.

You have no idea what "security through obfuscation" is. Open source is 
the exact opposite of that.

> Doesn't embedding the manifest make it actually less transparent, and
> harder to check if it was forged?

No, it does not. Any embedding manifest is visible through tools and 
properties of any application.

> Can an attacker not drop into a plugin directory a malware VLC plugin
> containing calls to reset the loader path preferences? Where is your
> dear security strategy after that plugin gets auto-loaded, on the floor?

So, since you have an issue, let's not fix the other ones?
I have a hole in my wall, but I won't fix it, because my window is open?

Why do you believe everyone else is so stupid that noone thought about 
that? That's exactly why we're discussing of checking the plugins 
signatures...

> Doesn't loading DLLs at run-time lower symbol checks and make it easier
> to craft a counterfeit library?

No, it does not. We're restricting loading from a system location, 
instead of loading it from everywhere else.
So, instead of just dropping a DLL in the VLC directory, you need to 
replace a system directory.

> Tampering with the VLC install directory is tampering with the VLC
> install, no matter how much you try to sugarcoat it.  Just because it's

The difference is between tampering with a VLC installation or a VLC 
unzipping vs tampering with the main Windows security.
We can make it harder to tamper with VLC installation, so we should do that.

> easier if you don't have to recompile VLC or patch compiled code or edit
> those pesky binary files, doesn't make it less tampering. And you're not
> protecting against tampering, you're merely burying "sensitive" parts
> deeper into binary code. This is snake oil. These patches improve the
> situation like obfuscation improves security.

Once again, you have no idea what you are talking about.
Everything inside the manifest is visible whether you embed it or not.
Also, wtf binary code? VLC is open source.

If you check, EVERY other main application is using embedded manifest, 
except us. Check the CIA document too, that mentions that directly.

> If you want to bloat winvlc.c with security duties of the system loader

bloat, by loading explicitly vs loading implicitly? Are you serious?

> and package distribution, because you believe they're safer there and
> less likely to be stripped or by-passed, why not also put there more
> countermeasures like cryptographic integrity of installed binaries at
> init, and scanning of installation directory for rogue wininet.dll, and

We're not scanning installation directory from known libraries, we're 
forcing them to be only loading from the system location.

> self-protect encryption of the signature table too? If you want more
> ideas I hear there were good concepts to pick from the Skype binaries.
> This sickens me.

So your point is that signing binaries is bad? Wow.
Then why are debian packages signed?

> So the CIA just grabbed one low-hanging fruit on the trojan-horse tree.
> Let's hurry to push many fixes to show that we're very concerned,

Noone is hurrying. We've been discussing all of those issues normally.
There are a few hijacking techniques, and we're making it harder to do 
those hijacking, one issue at a time.

Also, addressing the issues is important for our users, see the 
reactions on various social media. If you don't care about them, then 
fine, but don't attack people who do.

> I like this statement: https://pbs.twimg.com/media/C6V78U1WYAEaEvM.jpg

That has nothing to do with our case here. It is about the security of 
an app on an insecure system.

> Not afraid, educational, points out where the real problem is. I don't
> like VideoLAN's schizophrenic PR posture.

Now, we're schizophrenic? So you're down to insults?

> Overall, how disappointing again.

We're soooo much looking at your clever ways then, master, please 
educate us.


-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device


More information about the vlc-devel mailing list