VLC Update occurs over HTTP

It appears that VLC's updating mechanism downloads a new VLC executable over HTTP (ie, in clear-text).

This leaves users vulnerable to man in the middle binary replacement attacks.

This issue is described simply here: https://firstlook.org/theintercept/2014/08/15/cat-video-hack/

And more technically here: https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/

Please modify the update mechanism to happen over TLS (preferably with Forward Secrecy enabled)

Thanks so much!

-Morgan

Added attachment:

• VLC_Clear_Text.PNG

Sorry, but I don't see the point.

The update announcement files and the binaries are hashed and signed with our private key.

How can a "man in the middle binary replacement attacks" happen unless you have our private key?

and find a hash collision...

added Status::invalid label

closed

So, if you serve a older VLC, with the correct signature, and you serve the old status file and the old status file signature, and that on the same year of the current version, then you could:

• show a 'no upgrade' or
• serve a "VLC downgrade".

But:

• VLC does not auto-upgrade anyway, without user intervention, and
• the downgrade will be warned during the installer...

Note that the old status files are not public, so you'd need to plan a long time before... And it must be done the same way because of the validity of our privkey...

This is far from the "issue described above", or the usual HTTP shaming done on this tumblr...

Not to mention that seeing VLC uses GnuTLS, that is the most secure software ever, so using TLS would solve all the issues... (This part was irony, seeing that some people don't get it)

It's good to hear that the updater uses signatures, but I don't see anything about signatures for first-time installs at https://www.videolan.org/vlc/#download and the nice-looking https://get.videolan.org/ links actually redirect to HTTP mirrors.

Perhaps this should be a different bug.

Replying to [comment:5 wiretapped]:

It's good to hear that the updater uses signatures, but I don't see anything about signatures for first-time installs at https://www.videolan.org/vlc/#download and the nice-looking https://get.videolan.org/ links actually redirect to HTTP mirrors.

Perhaps this should be a different bug.

This is not about the updater, and is related to code-signing the binary for Windows. On OS X, the binaries are already code-signed.

Moreover, once you download VLC the first time, you are free to compare the hash and the signatures that are published with every release.

And get, in HTTPS gives you the correct hash.

So, if there is an issue, it's clearly not the same bug.

Note that this is exactly what happens for the linux distributions...

Btw https://get.videolan.org/ shows all the keys, the hash and the signatures under HTTPS, so you can check everything for your first time install...

I think the Linux situation is quite different, as (at least in the case of Debian and other dpkg-based distros) the distribution's archive signing key is making a cryptographic assertion that "this is THE thing called 'vlc'" and they even have some protection against rollback attacks (in the form of Valid-Until lines in Release files).

If I understand Windows and Mac code signing correctly, the assertion being made for first-time installs there is merely "this is a binary signed by someone who paid us a little bit of money for a code-signing cert". It is not difficult (or unheard of) for attackers to buy certs from Microsoft and Apple.

Replying to [comment:7 jb]:

Btw https://get.videolan.org/ shows all the keys, the hash and the signatures under HTTPS, so you can check everything for your first time install...

Thanks! It would be nice if that was easily discoverable from https://www.videolan.org/vlc/#download

Replying to [comment:8 wiretapped]:

I think the Linux situation is quite different, as (at least in the case of Debian and other dpkg-based distros) the distribution's archive signing key is making a cryptographic assertion that "this is THE thing called 'vlc'" and they even have some protection against rollback attacks (in the form of Valid-Until lines in Release files).

If I understand Windows and Mac code signing correctly, the assertion being made for first-time installs there is merely "this is a binary signed by someone who paid us a little bit of money for a code-signing cert". It is not difficult (or unheard of) for attackers to buy certs from Microsoft and Apple.

Replying to [comment:7 jb]:

Btw https://get.videolan.org/ shows all the keys, the hash and the signatures under HTTPS, so you can check everything for your first time install...

Thanks! It would be nice if that was easily discoverable from https://www.videolan.org/vlc/#download

Sorry, I fail to see what your points have to do with this bugreport.

For first time install, we allow people to check if their downloads are genuine, with our own hashes+signature (served over HTTPS) + code-signing on OS X (soon Windows too).

For the updater, see comment 4.

If VLC doesn't solve all of the issues covered by TUF, I'd say that VLC has some security issues with the installer/updater code:

http://theupdateframework.com/

Deploying TLS with HSTS and cert pinning will stop nearly all network attackers from executing the most serious attacks detailed on the TUF page.

...but for the most part, the VLC team has done a great job, and the original bug report as written was incorrect and misguided...

even though morgan's arrogance prevents him from acknowledging as much

Not true!

I'll cheerfully admit that the report was hastily written and poorly phrased.

Also, I love VLC :)

Replying to [comment:10 cypherpunks]:

If VLC doesn't solve all of the issues covered by TUF,

Sorry, but that statement is very vague.

If you have a particular issue, please report it, but "SOLVE ALL THE ISSUES" (meme) is too vague to be useful

In that case, I take back my earlier comments.

But for real, making huge scary claims at least partially via Twitter without first endeavoring to understand the broader context/ecosystem in which HTTP-based updates may occur can end up taking up one of the most scarce resources we have as a community: sec-oriented dev time.

Also much love to the VLC team for being responsive/respectful, and to Morgan for fighting the good fight and raising what I agree is an important issue. I'd still much rather live in an HTTPS-only world.

I didn't mean to make huge and scary claims, but I'll have to fall on my sword and admit that tweets like - https://twitter.com/headhntr/status/500708383582732288 - (which I meant with humor, hence the caps and exclamations) can be unproductive and add to FUD. For that, I apologize.

I would like still TLS on the download though even if the package signing is perfect. Defense in depth and all that :)

Replying to [comment:13 jb]:

Replying to [comment:10 cypherpunks]:

If VLC doesn't solve all of the issues covered by TUF,

Sorry, but that statement is very vague.

I've made it clearer in my response below.

If you have a particular issue, please report it, but "SOLVE ALL THE ISSUES" (meme) is too vague to be useful

There are myraid of problems pointed out in the following papers:

​A Look in the Mirror: Attacks on Package Managers
Package Management Security
Survivable Key Compromise in Software Update Systems

It seems that the VLC security team should read each of the papers and to declare that the issues contained within are resolved by VLC. Anyone implementing an updater needs to understand all of the issues involved.

To enumerate the issues from the TUF spec:

'' Rollback attacks. Attackers should not be able to trick clients into installing software that is older than that which the client previously knew to be available. ''

This is currently possible with VLC. This has been acknowledged in ticket:11987#comment:4, I think.

''Indefinite freeze attacks. Attackers should not be able respond to client requests with the same, outdated metadata without the client being aware of the problem. ''

This appears to be currently possible with VLC.

''Endless data attacks. Attackers should not be able to respond to client requests with huge amounts of data (extremely large files) that interfere with the client's system. ''

This appears to be currently possible with VLC.

'' Slow retrieval attacks. Attackers should not be able to prevent clients from being aware of interference with receiving updates by responding to client requests so slowly that automated updates never complete.''

This appears to be currently possible with VLC.

''Extraneous dependencies attacks. Attackers should not be able to cause clients to download or install software dependencies that are not the intended dependencies. ''

This appears to not apply during updates for VLC. That is good.

''Mix-and-match attacks. Attackers should not be able to trick clients into using a combination of metadata that never existed together on the repository at the same time. ''

This may be currently possible with VLC, I haven't looked in depth.

''Malicious repository mirrors should not be able to prevent updates from good mirrors.''

This appears to be currently possible with VLC.

It is not possible to download VLC over TLS in the first place - why not have a single HTTPS mirror for those that care?

The certs for the HTTPS hosts with GnuPG signatures should be pinned in popular browsers (eg: Chrome, Firefox, etc). That is not a matter for updates but it is a related issue.

I'm sorry, but some described attacks (Slow retrieval attacks, Endless data attacks) are issues that are the case for all download system like most Linux Distributions, and that will not be fixed. Mirrors are HTTP and will stay HTTP for a few obvious reasons. Moreover, they will install binaries, so there is no security issue. Moreover, downloads are never done automatically, without user intervention.

The 'Mix-and-match attack' is not possible because of status file signatures.

And the "Malicious repository" does not apply to VLC. Corrupted mirrors are removed from the pool.

So, only the "Rollback attack" and "Indefinite freeze attack" might be of concern here, and they could be fixed with using HTTPS on the update.videolan.org and carrying the hash of the file in the status file.

Finally, jumping and screaming on twitter, and spreading FUD, while most downloaders just use plain HTTP with no authentication, automatically, without doing the basic fact checking is extremely annoying.

Not to mention spending time on that, instead of taking down people like softonic, cnet, or all repackagers...