Attacks against GPG signed APT repositories(blog.packagecloud.io)
blog.packagecloud.io
Attacks against GPG signed APT repositories
https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/
13 comments
Hi!
I'm the author of the article. We never suggest turning off GPG and checksum verification.
The bugs may be in APT, but they allow several attack vectors against APT, as explained throughout. Let me know if you have any specific questions and I'd be happy to help clear things up!
I'm the author of the article. We never suggest turning off GPG and checksum verification.
The bugs may be in APT, but they allow several attack vectors against APT, as explained throughout. Let me know if you have any specific questions and I'd be happy to help clear things up!
Additionally the article appears to intentionally conflate "issues" such as "if you turn security off" or "if the repository isn't signed" to make their list of possible issues look bigger. None of these are "Attacks against GPG signed APT repositories".
We never suggest that you turn security off -- several versions of APT come with various settings defaulted to off, as described in the article.
All of the attacks presented (replay attacks, freeze attacks, and downgrade attacks) affect GPG signed APT repositories.
All of the attacks presented (replay attacks, freeze attacks, and downgrade attacks) affect GPG signed APT repositories.
What about replay attack? Providing apt with old metadata and packages?
Yes, plain text APT repositories (signed with GPG or not) are vulnerable to freeze attacks.
The release files have 'Valid-Until' fields, which will cause apt to reject it on replay.
APT will not reject it on replay if the 'Valid-Until' date has not been met yet.
Imagine a version of, say, libEXAMPLE has a vulnerability allowing remote code execution. The `Valid-Until` date is some time in the future, maybe a few days from now. The authors release a new version of libEXAMPLE to patch the vulnerability and the APT repository metadata is updated.
However, a malicious actor performing a MitM against your machine has saved the metadata with the vulnerable version. The malicious actor replays that metadata to your system, preventing your system from seeing the newly patched libEXAMPLE. This gives the attacker up until the `Valid-Until` date to attempt to launch an attack against you.
Imagine a version of, say, libEXAMPLE has a vulnerability allowing remote code execution. The `Valid-Until` date is some time in the future, maybe a few days from now. The authors release a new version of libEXAMPLE to patch the vulnerability and the APT repository metadata is updated.
However, a malicious actor performing a MitM against your machine has saved the metadata with the vulnerable version. The malicious actor replays that metadata to your system, preventing your system from seeing the newly patched libEXAMPLE. This gives the attacker up until the `Valid-Until` date to attempt to launch an attack against you.
The main recommendation is "always serve your apt repo over TLS", however, apt doesn't use TLS by design: https://whydoesaptnotusehttps.com/
The website you linked to has several factual errors, as explained in the article.
--force-yes is bad, but for reasons that have nothing to do with replay attacks.
This option effectively disables package authentication. This is because it forces "yes" answer to all questions, including the question about installing unauthenticated packages.
This option effectively disables package authentication. This is because it forces "yes" answer to all questions, including the question about installing unauthenticated packages.
Most of the 'attack' s are:
1. Plain old bugs in apt. 2. Involve disabling the very security features (GPG and checksum verification) designed to prevent that attack!