
VLC developers refuse to consider updates over HTTPS - GordonS
https://trac.videolan.org/vlc/ticket/21737
======
eps
[https://web.archive.org/web/20190119162021/https://trac.vide...](https://web.archive.org/web/20190119162021/https://trac.videolan.org/vlc/ticket/21737)

The issue appears to be that while VLC does in fact verify the authenticity of
a downloaded update, it also allows it to be signed with a key that it doesn't
yet know, in which case it will retrieve this key from the VLC servers _via
HTTP_. If that's true, it is a perfectly valid issue that needs to be
resolved.

However the tone of the original ticket _is_ a nasty one, which seems to have
resonated with the VLC dev in a wrong way.

~~~
arkadiyt
I reported the issue months ago [1], and I'm sure many have reported it before
me. The devs have been ignoring the issue regardless of this particular
author's tone.

[1]:
[https://trac.videolan.org/vlc/ticket/21422](https://trac.videolan.org/vlc/ticket/21422)

~~~
NicoJuicy
The site is down. But a valid threat model was requested and not given by the
original OP.

If there was a post with a valid threat model. That would be interesting,
until otherwise, it remains closed

~~~
arkadiyt
My ticket was closed without requesting a threat model. As a trivial example
this is a privacy leak - anyone on the network path can see what version
you're upgrading to. It doesn't sound like a huge deal but we are moving to a
100% encrypted world, and it is a one character change to fix the issue. If
VLC wants to keep the update over plaintext then they should justify why they
want to do that, not have users justify why it should be over https. Instead,
it feels like the VLC devs are having a kneejerk defensive reaction.

~~~
vbezhenar
You can check VLC website to know what’s the last version. It’s not a secret.
While I don’t know the reason to prefer http over https, the only legitimate
http threat is to serve non-latest version.

------
catwell
I am not an expert on VLC security, but here are a few things I can say.

1) The reaction is due to the fact that VLC developers know very well it
updates over HTTP on Mac. It has been reported at least 10 times in the past.

2) The comment mentioned by eps about the ability to MITM the key exchange is
probably wrong. The update code the poster was looking at is not the one used
by VLC on Mac, as JB Kempf (president of VideoLAN) commented. VLC uses Sparkle
which is a popular updater for Mac applications, not custom update code.

3) There _may_ still be a vulnerability. Typically apps that update over HTTP
and verify using GPG are vulnerable to an attack where the attacker serves an
older version vulnerable to _another_ attack, signed with the same key. There
are mitigations for that but I don't know if VLC uses them. The Sparkle
project itself advises the use of HTTPS for both the updates and the appcast
([https://sparkle-project.org/documentation/](https://sparkle-
project.org/documentation/)).

~~~
jbk
We do block downgrade attacks in the installer.

What you can do is freeze the update, but HTTPS will not change that.

~~~
marcoperaza
There is another attack where the user is updated to a _particular version_ by
a MITM. That is distinct from a basic version freezing attack.

~~~
catwell
This is almost what he said they block in the installer (downgrade attacks or
replay attacks).

The difference is there might still be an attack where:

\- User is at version N

\- Version N + x is vulnerable

\- Version N + x + y is latest

\- User terminal asks for N + x + y and the attacker serves N + x

However this attack is much less critical than anything letting an attacker
downgrade (only applies against versions updated infrequently).

Regarding VLC on Mac, which uses Sparkle, this issue could be avoided by using
HTTPS _just_ for the updates feed (AppCast), which is not mirrored.

~~~
jbk
This attack-to-not-latest exists, but it's very rare, since 99% of the
security issue we have are in all versions of VLC, because of old code (2000s)
in VLC and libavcodec.

It could happen, sure, but that is very far from the "OMG, updates are in
HTTP" issue, or even a downgrade attack.

------
NicoJuicy
What they mean is: a Man in the middle attack is very unlikely and not easy to
setup. They will not spend time on this issue untill the OP has a valid threat
model. Which the OP has not given.

They already cryptographically sign and validate the updates, which is why it
is ignored. It's another solution for the same problem ( reducing change of a
malicious update)

PS.

> This is a security risk and should be solved ASAP. Thanks

This has a unfriendly tone of the OP. I would have done the exact same thing
in the same situation as the VLC developers ( since there is already a
solution implemented).

~~~
eponeponepon
Yeah, this doesn't really hold water when your software is as widely installed
as VLC - I've lost count of the number of _deeply_ nontechnical people I've
installed it for, for what that's worth. Checking file sizes is serious half-
assing IMO - it's not beyond the wit of teenagers running a botnet to deal
with that, never mind determined criminals.

~~~
NicoJuicy
NASA could also be hacked by determined criminals, VLC hasn't got unlimited
resources to spend. The HTTPS change could be easy, but you don't know what
other things can be affected at first glance ( eg. update mechanism on older
versions with no https support).

If the attackers can do a MITM, they probably also have other stuff at their
disposal :)

But more important, issue the bug with a valid threat model and it could be
fixed. As long as there is no threat model and perhaps an active discussion (
this is how open source works), the ticket stays closed.

The OP had 2,5 days to respond.

~~~
DoctorOetker
so suddenly the onus of developing the threat model is on the user?

I believe both devs and users should have the liberty to discuss and propose
threat models, but if there already is "some level of precaution" the real
question is where was the previous threat model that dictates signing? or is
this security theater?

~~~
NicoJuicy
If the developers think there is no threat. Then yes, it is for the user to
prove this.

~~~
DoctorOetker
you can't prove a threat model. a threat model is part of what is in or out of
scope.

the first thing that should happen is for VLC dev to set up a threat model, if
the user base disagrees with the narrow scope of the VLC threat model they
should fork.

the second thing that can then happen is that given a threat model, a user
could file a bug report to complain how a certain hypothetical attack (within
scope of the threat model) violates the security.

think about it this way: for all non-security bugs, would you ask users to
"prove that resolving a certain bug is within scope of the project"? how can a
user prove what is within the developers' scope?

~~~
theamk
I think you are making a wrong analogy here. A "threat model" in security is
like a "user operation" for the feature.

So in the non-security bug world, the exchange would look like:

Bug report: the program is missing blue circle in the top right corner. Please
add is ASAP.

Developer response: what would possibly be the use of this feature? Please
tell me of I will close the bug.

~~~
NicoJuicy
Here is a decent developer response:
[https://www.beauzee.fr/2017/07/04/videolan-and-
https/](https://www.beauzee.fr/2017/07/04/videolan-and-https/)

------
Eli_P
Oracle's practiced the same policy with VirtualBox distributions and that's
been fine because they signed packages. VideoLAN signs their packages too. It
seems to be a common practice for a highly loaded services to outsource as
many cryptography to clients as possible. I think for the same reasons Google
dropped CSRF tokens for their api in favor of different security measures.

~~~
CapacitorSet
This isn't any different from many download procedures. Consider that even a
general-purpose package manager like Pacman uses HTTP, because there's little
point in using transport-level security when the payload is cryptographically
signed and there's a solid root of trust.

The only reasonable problem I see with this approach is that a MITM can make
clients download an older version that is known to have critical bugs.

~~~
msbarnett
> This isn't any different from many download procedures. Consider that even a
> general-purpose package manager like Pacman uses HTTP, because there's
> little point in using transport-level security when the payload is
> cryptographically signed and there's a solid root of trust.

This IS different.

If the VLC update is signed with a key not known to VLC, VLC will then go
fetch the new key from the update server over HTTP, and not verify the key in
any other way.

This renders the cryptographic signing of the updated binary a complete no-op.
Anybody in a position to tamper with the HTTP download of the signed binary
can equally change the HTTP downloaded, unverified key VLC retrieves to verify
the signing. It is effectively unsigned, and the root of trust is as solid as
mist.

~~~
theamk
No, this is not the case, as many other people in the thread said.

------
jdietrich
I might be missing some context, but I am deeply unimpressed with how Rémi
Denis-Courmont chose to handle this. As far as I can tell, Rodger Combs gave a
perfectly lucid explanation of a plausible threat model. If this is how the
VLC developers typically handle security issues, then I'm unsurprised that the
EU has decided to offer a bug bounty.

[https://www.zdnet.com/article/eu-to-fund-bug-bounty-
programs...](https://www.zdnet.com/article/eu-to-fund-bug-bounty-programs-
for-14-open-source-projects-starting-january-2019/)

~~~
coldtea
Well, it's not the first time he has been controversial, e.g:

[http://cdm.link/2011/01/as-apple-pulls-gpl-licensed-vlc-
the-...](http://cdm.link/2011/01/as-apple-pulls-gpl-licensed-vlc-the-
developers-version-of-events-what-it-means-for-free-video-2/)

[https://www.reddit.com/r/apple/comments/h6jmp/r%C3%A9mi_deni...](https://www.reddit.com/r/apple/comments/h6jmp/r%C3%A9mi_deniscourmont_the_asshole_who_got_vlc_off/)

[https://arstechnica.com/civis/viewtopic.php?f=14&t=1133166](https://arstechnica.com/civis/viewtopic.php?f=14&t=1133166)

~~~
temac
I saw no controversy in at least the second (reddit) link, appart from an
anonymous coward insulting him and making random gratuitous hypothesises -
moreover likely unrelated to anything...

~~~
coldtea
Isn't having some people against you the very definition of controversy?

------
mfer
This looks like it went bad because of poor communication. There is a lesson
in that. For both sides.

For example, what would have happened if the reporter had either reported the
security issue via the security process, to people who should understand this,
or took a moment to explain the that model.

Or, what if the person who responded had politely asked for more detail or
asked the security issue to be handled through that process?

How we treat people can make a world of a difference

------
marcoperaza
If the updates are cryptographically signed and validated, then it makes no
difference. A MITM would just be giving free bandwidth to the VLC project.

The best argument is for defense-in-depth—in case someone breaks their signing
scheme.

Edit: u/dcbadacd makes a great point about old but vulnerable versions
potentially being served up by a MITM.

~~~
cjbprime
The issue says that the cryptographic checking is broken, and accepts new
public keys as authoritative in the presence of MITM.

Which makes the report totally valid, if true.

~~~
mitchtbaum
VLC checks the downloaded file using the newly downloaded key??

------
aritmo
The big issue is that HTTP increases greatly the attack surface of VLC. The
VLC client needs to parse the response from the "update server", and this
response must be considered as potentially 100% malicious.

~~~
jbk
Of course not. The response is GPG-signed.

------
cataflam
Mirror as the bugtracker seems to be taking a beating from the post:
[https://archive.fo/Dmtwo](https://archive.fo/Dmtwo)

------
heyjudy
Q: Is this a Sparkle (popular non-MAS update framework) insecurity issue?

I use the long dead Bodega client to discover and check all local apps for
Sparkle updates manually. I wish there were a similar app that both checked
for updates periodically and checked the security model of each app's update
server implementation (it's a difficult problem to audit the client's update
security).

------
pferde
Refuse to consider, or have considered and refuse to implement? Two very
different things.

------
amaccuish
iTunes does the same thing (signed downloads over HTTP):
[https://news.ycombinator.com/item?id=18582060](https://news.ycombinator.com/item?id=18582060)

