Hacker News Reader

Comment by wildmusings | Hacker News Reader

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.

View on HN

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.

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.

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.

Absolutely not: the installer blocks downgrade attacks.

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.

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.

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.

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

The issue is wrong.

Reply on news.ycombinator.com