3 ms·

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

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 8y ago
We do block downgrade attacks in the installer. What you can do is freeze the update, but HTTPS will not change that.
- marcoperaza 8y ago
  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 8y ago
    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 8y ago
      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.
- deleted 8y ago
  [deleted]

jbk 8y ago

We do block downgrade attacks in the installer. What you can do is freeze the update, but HTTPS will not change that.

marcoperaza 8y ago
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 8y ago
  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 8y ago
    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.
deleted 8y ago
[deleted]