Even though most people consider downloading your Linux software from you own distribution's repositories as safe, thinking about the scenario where a repository gets hacked sounds thrilling.

What would happen if a repository which hosts widely used applications gets hacked and those applications are replaced (or added) with viruses/trojans/malwares? How fast would that be noticed, and did anything like a "repository hack" happened in the past and lots of machines got affected?

I'd expect that hacking the repo server itself is little more than a DoS attack. You'd need to hack the machine signing the package, or convince its operator to sign a package that contains a virus.
–
CodesInChaosMay 7 '12 at 8:46

This is covered in SANS SEC504 or Counter-Hack Reloaded by the awesome Ed Skoudis. Short answer is: it has happened quite a few times with small scale effects.
–
adricMay 8 '12 at 12:22

4 Answers
4

Well, since this almost happened, one of the first things would be an article on LWN!

As you can see from the previous post about kernel.org, occasionally servers used to distribute packages and code are compromised, just like any other. Exactly how much damage can be done really depends on the level of the compromise, but if a signing key passphrase were captured, the attacker could sign any package they liked, passing it off as a package distributed by the distribution.

The upshot of this would be that client systems would accept the update and the user would be none the wiser - at least until the distribution realised and shipped updated keys and investigated what had been altered.

Unfortunately there isn't much you, the end user, can do to protect against this - the only way you'd know is by analyzing your system for malicious behaviour and (hopefully) finding it.

Before you consider this a Linux-only problem - remember, many companies push updates out from servers, or rely on central signing code. The same set of risks apply (and are even worse if no signing is done). Compromises to root CAshave happened, and the consequences are pretty similar - you end up with a connection that appears valid, that you cannot actually trust.

All of this comes down to a central trust model having a single point of failure, as opposed to the web of trust model which attempts to decentralize the issue. Web of trust models, however, have their own problems.

Note that in the case you cite, it wasn't a repository that was hacked, but a signing machine. This is an important distinction: there are many repository mirrors around the world, usually only distributing public files, and by definition publicly accessible. Signing machines are few and accessible only to a few project members. If a repository is hacked and the project signs its packages and the package installation software verifies signature, then a repository hack is only an inconvenience, whereas a signing machine compromise is a big deal.
–
GillesMay 8 '12 at 23:59

Note that kernel.org was, in fact, hacked. There is an interesting analysis of how this did not affect any downstream provider. Basically, the primary reason why this attack did not yield any significant results was due to the Git source control system that is used.

There are mitigating factors; mirrors, signatures, checksums, etc. Hiding this sort of thing for more than just an hour or two would be difficult in most circumstances, so this type of thing tends to be discovered and remedied before it can do any damage.

What's much more troublesome is if an official source code repository for a package gets hacked and the sources modified. This has happened to a few projects, and is a major selling point for doing decentralized development like you see with the Linux kernel. That way there is no central repository to hack.