A friend of mine just had the strangest kind of problem where his Fedora 20 would not update to (or even find) the current kernel 3.16.3 (and incidentally also not update the vulnerable bash version). After clearing caches, comparing his and my config files and a lot of head scratching I finally remembered he was using a VPN and asked him to turn it off and try again. It worked flawless outside the VPN. My guess is that the vpn enforces http proxying with an aggressive cache.
That got me thinking about the security assertions yum can give its user. Apparently it can not detect replay attacks on the repository database, as he did not get any warning or error message about a stale repository state. I would have assumed the repository overview was time stamped and signed regularly or fetched over HTTPS (or a hash of the database would be fetched over HTTPS to reduce the bandwidth of the encrypted traffic).
I know that signatures on the individual packages are checked, so I can at least be assured that no package can be installed on my system that was not authored by a trusted party. But how about partial updates? Can a malicious proxy or mirror selectively deny package updates? E.g. never update the vulnerable bash package but forward every other update so I won't get suspicious about not getting any updates at all?
Or even worse, can an attacker even selectively downgrade packages? E.g. re-install the heartbleed susceptible openssl package?
Best Answer
I'm answering from the perspecting of
apt, but I believe this is all the same foryum.Updates are fetched over HTTP or FTP, not HTTPS. The idea is that the payload doesn't need to be encrypted, only unmodified, so "sufficient" security is achieved by a PGP signature on the index. But the replay attack is a problem!
In order to be scalable, updates and indices must fetched from a "dumb mirror" system, so the mirrors can't do per-connection computations. Theoretically, it would be possible to use a second system just to fetch the index and use dumb mirrors only for the bulk data.
Obviously, it is impossible to guarantee that you can connect with the server. If you trust your local system's clock, you could check a timestamp that is included as part of the PGP signature. This would require a little bit of extra infrastructure to guarantee that the signature is regenerated daily even if the contents don't change, but that would be a good idea for detecting stale mirrors anyway.
For the last part of the question - no, it is not possible to force a downgrade. A fundamental aspect of package management is that if the remote repo contains an older version than what you currently have, it does nothing.