points by mikepurvis 4 days ago | 0 comments
MITM on the network, I guess like DNS takeover or the like.
So you pass through the upstream headers but then simulate a failure/resume and supply different contents for the resumed download.
So you pass through the upstream headers but then simulate a failure/resume and supply different contents for the resumed download.
[–] SoftTalker 4 days ago
[–] dinosaurdynasty 4 days ago
from the OP
APT can use HTTPS, but often doesn't, making a MITM attack easier (also the idea for a long time has been signatures are enough, and/or TLS certs used to be a lot harder to get, but at this point you should really be using both).
[–] SoftTalker 4 days ago
[–] xeyownt 4 days ago
To summarize, APT may have several download sessions in parallel, which may download the same "resources". To save bandwidth, disk storage, these same resources are downloaded only one, but given different names on the disk through hard links.
Because of HTTP retry, APT may be lured into downloading again a resource, but that was associated with a different package name, package that was already checked (hash verified). This is because of some differences between the package name / filename / URI, etc.
Anyway, the point is that hash are verified when a package is completed, but because of possible parallel downloads and hard links usage, a verified package can be rewritten.
What I find crazy though is that why packages are not first completely all downloaded, then every time a package is used, the hash be verified before being used. This would reduce even further the surface of attacks, and I don't care about any performance impact.
[–] SoftTalker 3 days ago
Yes I'm amazed to learn this is not the case. Without that, any local exploit that could replace a file could potentially replace a downloaded, "already verified" package.
[–] tosti 4 days ago
[–] thayne 4 days ago
One reason http is still used is because you need an independent signature anyway since it is common to use mirrors that don't have the same level of trust as the debian maintainers