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

[Pierre Ynard]

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

I believe you understood what I really meant. But thank you for pointing
out the fact that VLC is open-source, and as such, the security patches
that you push are moot since it's so easy for an attacker to strip them
from the source and rebuild binaries, or patch binaries directly, or add
any other piece of malware in another way.

> 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?

You wake up in the morning, your paint is peeling, your curtains are
gone, and the water is boiling. Which problem do you deal with first?

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

Or maybe it's not being stupid but just acting stupid to support PR
postures.

> If you check, EVERY other main application is using embedded manifest,
> except us.

If you leave it at that, your argument is cargo cult.

> Check the CIA document too, that mentions that directly.

"A horrendous crime has been committed using [something], let's pass a
new law to ban [something] so it can never happen again!"

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

Yes, very much so.

> We're not scanning installation directory from known libraries

Well maybe you should, it would be a step up from what was done.

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

Once again I believe you actually understood what I really meant.
Signatures of Debian packages are good and enforced by the package
manager. My point is that if you're dissatisfied because it's too easy
to tamper with the VLC installation directory, maybe you should improve
the packaging to ensure integrity, instead of fiddling with vlc.exe
without protecting it against tampering.

> 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 don't know if you care about the users, and I don't know if you do
this out of care for them. To me, you come off as caring about your
corporate interests. And maybe that's just me but I feel you care more
about them than about my interests as a developer.

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

Well, first, I disagree. If you can't use the normal link mechanism of
an OS to load its system libraries because it opens and exposes you to
attack vectors, this is an OS security problem.

Then, and I hope you understood what I meant, the real point is the
Telegram statement expresses one simple message in a clear way.

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

If I was down to insults, it's not schizophrenic I would call you ;)
Besides, that's not very politically correct.

When I read the mailing list, the commit log, the PR statement, I don't
feel much soundness or oneness in what's going on: I see different
efforts to cover several fronts at the same time, all opposed to each
other. Even just looking between the different paragraphs of the
statement, I see:

 - reduction of the scope of the exploit, down to not-normal conditions
 - likening to an almighty trojan horse and putting responsibility on
   the user to get official binaries
 - VideoLAN taking responsibility to fix it as a VLC issue
 - a generic well-meaning belief statement hardly connected to the rest

So is the issue not a grave issue, a user issue, a VLC issue, an
open-source standards issue? All of them at the same time? For PR's sake
you might want to pick one message and stick to it.

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

I already gave some suggestions. I spot a lack of user education about
how running a portable version of VLC is a security issue. It by-passes
security features of packaging and distribution, and I believe that's
significant. To state the obvious, instead of going through packaging
logic and using admin privileges to install to a privileged directory,
portable VLC is usually run from an unprivileged, writable directory,
making it easier to tamper with it.

Moreover if it's stored on and run from removable media, I can't
imagine any good mechanism to maintain integrity. So I don't see valid
approaches apart from user education and discontinuing portable VLC.

We disallow running as root, so we could disallow running as portable,
or prompt an educative or discouraging popup. It could check if
VLC is running from an unprivileged directory. If your interest in
unreliable countermeasures persists, I mentioned other ones that are
still less backwards to me than refusing to link against libraries
normally. Using introspection APIs to check where libraries were loaded
from - or if impossible, scanning the directory for rogue DLLs - and
aborting if necessary. Checking that the installation directory is not
writable. Checking that the installation directory was not written to -
actually some filesystem timestamps cannot be tampered with without raw
filesystem access.

As part of the privileged installer, would it be possible or desirable
to extend the KnownDLL list to cover system libraries that VLC uses?
That could be a better and more straightforward solution, and could help
push in the right direction towards the real OS issue getting fixed.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."