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).
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.
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.
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?
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?
While yes, it is considered weak, that doesn't mean it is useless. Git uses Sha1 and a lot of other services do as well. Using it to validate and sign an update is probably still pretty much safe as I have only ever seen or heard of a single SHA1 collision ever. And that was in 2017. It took them 6500 years of CPU computation time and 110 years of GPU computation time to find it. I think we can consider SHA1 good enough to sign VLC updates for now.
I brought the same issue up with Tesla about their firmware updates not being encrypted in transit, and their argument was the updates are cryptographically signed. Good enough I suppose.
In fact, if the HTTPS change is faster, this should be prioritized, given that the other issue might take a lot of time to fix: the old validation mechanism will have to be supported for a long time to keep older clients backwards compatible...
I'd take that the VLC guy had a bad day, otherwise that'd be a terrible reaction from someone involved in computer security.
We have no knowledge of "technical debt" or technical issues migrating from http to https. Videolan has 5 applications, perhaps all of them use the same update mechanism, which would broathen the scope of the fix.
What seems trivial (i agree), isn't always that in the software world. We need business knowledge of the VLC source or architecture for having a clear decision.
For what it's worth. I'll give the VLC developers the benefit of the doubt.
I can see plenty of issues for the users if they just change http to https.
All the installs in a professional network where the use of a proxy changes the certificate would have trouble updating. So now it is changing changing http to https and be able to recover the company certificates in some way, in many different environments.
So yeah, the change is not trivial and will likely break the setup of millions of users. Downloading over http with a proper signature mechanism can be safe and is much easier for the users. If people have concerns over the way VLC is doing it, they are free to show how this can be broken and offer a fix.
> All the installs in a professional network where the use of a proxy changes the certificate would have trouble updating. So now it is changing changing http to https and be able to recover the company certificates in some way, in many different environments.
Presumably those "professional networks" also use other software that already updates over HTTPS, this is not really VideoLAN's problem in 2019 when we are moving towards HTTPS everywhere.
I remember when Microsoft released Win7 the ISOs were downloadable through HTTP direct links, and MS published the hashes on an HTTPS page. Similar idea, different implementation... and if cryptographic signing is good enough for a company like Microsoft, it should be good enough for VLC.
I don't know who is right, but you claim the update needs to be signed, but eps says that it also allows the update to be signed by a key retrieved over insecure HTTP which of course can be MitM'ed. I guess the threat model includes malicious ISP's / governments, so as a user you want a clear delineation of responsibility, and have VLC either 1) use a backup master key to sign the signing key, so if the signing keys is compromised a new key can be issued from an airgapped system or 2) insist VLC retrieve the second key over HTTPS. I would prefer 1) though...
hm.. we have one of the software authors and a random by-stander arguing about the code? I know who I would bet on.
(Note that if it were a political question, then yes, opinions of any random bystander are potentially as valuable as software authors'. But it is not. I need to see a specific evidence before trusting random strangers)
>> This is a security risk and should be solved ASAP. Thanks
> This has a unfriendly tone of the OP.
Having lived on both sides of the pond, I'm aware of differences, but in which culture is that considered rude?
You're addressing computer geeks, not the King of Thailand.
I read ASAP as "as soon as possible", which arguably applies to all security bugs.
> The thanks afterwards is meant for after they have done it and makes it worse.
That used to trigger me in the past as well, but it is deeply ingrained in corporate communication (at least of West Coast USA). Just ignore it, you can't fight it.
> Which would be something what a boss would say.
I thought so in the past as well, but now everybody uses it.
I've noticed that anything "security" related tends to attract lots of loud-mouthed authoritarian cargo-culting do-gooders, and for this reason I prefer to distance myself from them as much as possible. Perhaps it's a prerequisite for this type of work (in the real world, think of police, TSA border guards, etc...)
You don't know what you are talking about and accuse others of your very sins just because of internet points...
FYI mitm attacks have been employed against high profile targets, and VLC is deployed pretty much everywhere. This is a very plausible persistent threat scenario, not a mere theoritical issue...
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.
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...
Trac is written in Python, one of the slowest languages that there is. Posting a link to a Trac installation on HN is practically an act of terrorism; the server it's hosted on might explode and expose you to civil liabilities. You should check with a lawyer.
We don't really know what it's written in anymore, since the new version is closed source, but given that they had to rewrite it because of how slow it was, it's unlikely they chose Python again.
They never claimed to be rewriting it, just that it would no longer be open source. They still have a few Python components actively working. I think it's safe to say Reddit hasn't migrated to a new language secretly.
They are signed with 1024bit DSA with SHA1, every piece of that combination is considered obsolete cryptography nowadays. Even the NIST dictates you shouldn't sign anything new with that.
Signing also doesn't stop serving old-and-vunerable-versions as the latest which is in my opinion a vunerability. Apt also has that vulnerability.
Good point about old-and-vulnerable versions. That seems like a strong argument in favor of using HTTPS. I’m curious why the Debian folks haven’t thought this a serious issue either. I’m going to try to dig up the discussions.
But the use of a weak signing scheme is just an argument in favor of switching to a better signing scheme. Though I guess it is also real world evidence in favor of defense-in-depth.
Version freezing attack can be done even if the client tries to connect over TLS, simply by dropping SYN requests to the update server, or by DNS manipulation, etc.
That’s not quite the same attack. What you describe can only keep you from updating at all, freezing you at whatever your current version is. The attack described above would let the MITM choose the exact version to update you to.
I’m not talking about a downgrade attack. I’m talking about upgrading to a known vulnerable version. You are at version X, attacker upgrades you to known vulnerable version X+1, even though the real latest version X+2 has a fix.
There's a difference between "failed to contact update server" and "no new updates found", though. And DNS manipulation wouldn't work if certificate pinning is used.
Here's the scenario that the original reporter added:
> if the update blob indicates a key other than the hardcoded one, it downloads the requested public key from the VLC update server over HTTP and does nothing further to verify the key itself. This means that all an attacker would have to do to serve a malicious update would be to sign it with their own key, then serve the matching public key when VLC requests it.
I think they should've included this in the original report, because if true then it really changes the severity.
Yeah, that changes everything if true. But the subsequent comments on the bug report allege that the new key is in fact verified against the hard-coded public key.
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.
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.
> 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.
Thant's an interesting observation, possibly can be solved with a signed version file, which is released daily. Signing of (datetime, version, package_image_hash) can be done with CI daily or hourly and probably way faster than encrypting the whole traffic.
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.
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.
The threat was given by the comment, and a good community manager or developer would have acknowledged that and not have continued to act obstinate. They are actively ignoring it.
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.
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.
Your issue is long after they were having this as an annoying argument version of the report (and it is really difficult to isolate "well this one guy might have sounded sane"; at some point you burn out even thinking about the issue).
> 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.
That is absolutely untrue. The commenter failed to read 10 lines under the verification of the new key against the old key.
Everything is checked against a public key that is inside the binary.
Let's assume that the upgrade can be safely downloaded. The potential attacker / authorities will still know that the device has VLC installed with which version.
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
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/).
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.
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.
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).
102 comments
[ 3.5 ms ] story [ 164 ms ] threadThey 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).
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.
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?
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?
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.
Yes, but it adds load on download servers and increases the cost of serving VLC to users.
https://security.googleblog.com/2017/02/announcing-first-sha...
https://www.cryptologie.net/article/466/developers-are-not-i...
1) PS ...{text} and would loathe the open source model for a second.
2) PS2. Some sign of respect to developers would be nice (y)
3) ...
But haven't found a good one. Your comment is better
:)
End result for this issue is the same. Also, a comment is not the same as posting a bug.
In fact, if the HTTPS change is faster, this should be prioritized, given that the other issue might take a lot of time to fix: the old validation mechanism will have to be supported for a long time to keep older clients backwards compatible...
I'd take that the VLC guy had a bad day, otherwise that'd be a terrible reaction from someone involved in computer security.
We have no knowledge of "technical debt" or technical issues migrating from http to https. Videolan has 5 applications, perhaps all of them use the same update mechanism, which would broathen the scope of the fix.
What seems trivial (i agree), isn't always that in the software world. We need business knowledge of the VLC source or architecture for having a clear decision.
For what it's worth. I'll give the VLC developers the benefit of the doubt.
VideoLAN isn't in a position to enforce it's hosts to serve the files over TLS.
However the cryptography of the signature check will be updated in the future.
[0] https://whydoesaptnotusehttps.com/
All the installs in a professional network where the use of a proxy changes the certificate would have trouble updating. So now it is changing changing http to https and be able to recover the company certificates in some way, in many different environments.
So yeah, the change is not trivial and will likely break the setup of millions of users. Downloading over http with a proper signature mechanism can be safe and is much easier for the users. If people have concerns over the way VLC is doing it, they are free to show how this can be broken and offer a fix.
Presumably those "professional networks" also use other software that already updates over HTTPS, this is not really VideoLAN's problem in 2019 when we are moving towards HTTPS everywhere.
So the issue should still be closed according to the supplied information in the bug post submission.
I don't know who is right, but you claim the update needs to be signed, but eps says that it also allows the update to be signed by a key retrieved over insecure HTTP which of course can be MitM'ed. I guess the threat model includes malicious ISP's / governments, so as a user you want a clear delineation of responsibility, and have VLC either 1) use a backup master key to sign the signing key, so if the signing keys is compromised a new key can be issued from an airgapped system or 2) insist VLC retrieve the second key over HTTPS. I would prefer 1) though...
hm.. we have one of the software authors and a random by-stander arguing about the code? I know who I would bet on.
(Note that if it were a political question, then yes, opinions of any random bystander are potentially as valuable as software authors'. But it is not. I need to see a specific evidence before trusting random strangers)
> This has a unfriendly tone of the OP.
Having lived on both sides of the pond, I'm aware of differences, but in which culture is that considered rude? You're addressing computer geeks, not the King of Thailand.
The thanks afterwards is meant for after they have done it and makes it worse.
What he actually says is: The bug is posted, I offered the solution. Fix it and I won't follow up on this.
Which would be something what a boss would say.
> The thanks afterwards is meant for after they have done it and makes it worse.
That used to trigger me in the past as well, but it is deeply ingrained in corporate communication (at least of West Coast USA). Just ignore it, you can't fight it.
> Which would be something what a boss would say.
I thought so in the past as well, but now everybody uses it.
Thanks for clarifying :)
EDIT: wow, surprised at the downvotes! I guess many HNers don't understand security that well.
FYI mitm attacks have been employed against high profile targets, and VLC is deployed pretty much everywhere. This is a very plausible persistent threat scenario, not a mere theoritical issue...
And the releases are themselves signed. http or https doesn't matter.
https://news.ycombinator.com/newsguidelines.html
https://www.zdnet.com/article/eu-to-fund-bug-bounty-programs...
http://cdm.link/2011/01/as-apple-pulls-gpl-licensed-vlc-the-...
https://www.reddit.com/r/apple/comments/h6jmp/r%C3%A9mi_deni...
https://arstechnica.com/civis/viewtopic.php?f=14&t=1133166
... `with a layer` ... rofl
Powering some of the largest sites on the internet. It's about how you write it and what you use (e.g. async python can be faster than Node).
This "slow language" accusation is straight out of "teenager just learned to program" style cliches...
Actually Reddit is written in Python still. It was originally written in Lisp, but they rewrote it simply for more familiarity.
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.
Which makes the report totally valid, if true.
Signing also doesn't stop serving old-and-vunerable-versions as the latest which is in my opinion a vunerability. Apt also has that vulnerability.
But the use of a weak signing scheme is just an argument in favor of switching to a better signing scheme. Though I guess it is also real world evidence in favor of defense-in-depth.
> if the update blob indicates a key other than the hardcoded one, it downloads the requested public key from the VLC update server over HTTP and does nothing further to verify the key itself. This means that all an attacker would have to do to serve a malicious update would be to sign it with their own key, then serve the matching public key when VLC requests it.
I think they should've included this in the original report, because if true then it really changes the severity.
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.
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.
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.
[1]: https://trac.videolan.org/vlc/ticket/21422
If there was a post with a valid threat model. That would be interesting, until otherwise, it remains closed
And you haven't read my comments here. Which said we don't know the whole story.
Read the above link and don't believe everything you read online. I have given the developers of VLC the benefit of doubt. Rightfully, so it seems
https://trac.videolan.org/vlc/ticket/11987
"Are you sure? For me it verify_signature() for the new key, based on the hardcoded public key."
And concerning the fact that the ticket is open for OsX : "As for OP, the updater on macOS uses Sparkle, and clearly not this update code. "
That is absolutely untrue. The commenter failed to read 10 lines under the verification of the new key against the old key.
Everything is checked against a public key that is inside the binary.
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
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/).
What you can do is freeze the update, but HTTPS will not change that.
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.
It could happen, sure, but that is very far from the "OMG, updates are in HTTP" issue, or even a downgrade attack.
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).