Attacks on Package Managers
 

Ran into this interesting link on Slashdot today, and I thought it might make for a good discussion here.Complete Article

Can anyone access http://www.cs.arizona.edu/
?
Or did they get hit by their package manager revenge? :)

Maybe it corresponds to some concerns I had about a particular thread about apt repositories:
http://www.linuxquestions.org/questi...35#post2717035

Yeah, the site appears to down at the moment.

Hopefully the article will be accessible again later today.

In the meantime, here's a link to a CERT synopsis of the article.

I read the full article last night (am in UK) and it's extremely interesting. The authors were able to set up approved mirrors for several major distros with no worthwhile checks being made. They had used a front company and were not identifiable. The biggest opportunity this gives them is not to insert compromised packages but to withhold security patches by simply using old package lists/metadata or manipulating those lists which generally aren't keysigned in the same way as packages. From then on it's extremely easy to collect IP addresses of each visiting client and target them with exploits for the known vulnerabilities. The clients are of course unaware that they have beeen offered incomplete or old package lists (unless there is a conscientious admin/user who subscribes to security mailing lists or similar), all the packages obtained are keysigned, they're happy.

Even if a malicious person can't get his mirror approved he can use a man in the middle attack to achieve the same result because generally distro repos don't use https, only http or ftp. Commercial distros such as Red Hat and SLED/SLES are notable exceptions. And most distros don't keysign metadata or package lists, only packages.

It's an incredibly effective attack which relies only on the end user to trust the official repositories and the update mechanism. Anyone who completely relies on automatic update notification and management without taking an interest in security mailing lists, forum security notices etc is wide open to exploitation.

There were some other aspects to it but this would seem to be the principal avenue of attack.


edit: as an aside, a couple of years ago I encouraged a friend to try Ubuntu. He's an extremely experienced and capable programmer, I believe from assembly language upwards, with a strong interest in security. He had been kind of enmeshed in MS stuff and projects of his own concerning a radical approach to secure anonymous voting systems and was only peripherally conscious of contemporary distros. The same day he installed it he identified the package management as an easy target for attack. I was doubtful due to keysigning, but he was insistent that by using man in the middle attack he could do exactly as the article described. I naively(?) assumed that we were both missing something and that the various distro maintainers must have considered this and dealt with it. I'm sure that plenty of other people must have come to the same conclusion as my friend and some will inevitably have tried to act on it.

Thanks win32sux

Ok for MiM attacks.

I take the case of debian because it's the only one I know.
Isn't the release file gpg signed?
Release.gpg is the list of packages from what I understood?
http://wiki.debian.org/SecureApt

I don't get it..

Scenario:

A malicious repo has all the packages genuine and signed, the release file genuine and signed....but not current. The client's package manager accepts the keys as genuine because they are indeed genuine, however the repo maintainer has deliberately not updated the repos, all hosted release files and packages are perhaps from yesterday or last week, and so the client doesn't receive security patches x y and z which were released today and for which the repo maintainer has exploits. He simply collects all visiting IP addresses and soon has a nice long list of exploitable clients.

edit: The important point is that at no point has the malicious repo offered anything but genuine signed packages and signed release files. Basically the exploit is based on users trusting the distro/vendor to effectively authenticate and audit not just the mirrors but the maintainers of the mirrors. In fact this authentication and auditing is proven to be ineffective, and the users' trust is misplaced.

Ah ok I got it. Thanks. I had to look at http://mirror.debian.org/status.html and http://www.debian.org/mirror/list
I had forgotten how many repositories debian consider safe. Hum maybe too much.
The distro maintains a list of repo that they consider safe. But they are safe (are they even checked at this time?) at a certain time. If the mirror is not updated or if a virus is injected in this mirror, you get it.

Yes. I don't see anything new here. Same with non package managers, from source or anything. It's a bit like when people said "wouah firefox has vulnerability, you can get fooled by installing broken extensions!".

I agree that there should be a kind of top level check with revocation list or something.

Personnally I only take class-1 servers which are hosted at debian.org. I trust them (who else could I otherwise). It's only if they get compromised that I will get also. This already happened once to them but it was spotted quickly. I don't trust anybody else. I don't load any other keyring and don't install unauthenticated packages.

The official mirrors can be fine and uncompromised but the clients are still vulnerable to man in the middle as long as the transaction is done via http instead of https. Even connecting to a maliciously hosted mirror it's extremely unlikely that a malicious package could be offered without flagging up a "not authenticated" warning. This isn't really a great danger now that packages are signed.

The real danger is in the mirror deliberately not updating. There are always some mirrors which are out of date (and various other problems) as can be seen at http://mirror.debian.org/status.html so it would not necessarily indicate any serious issue. If I was hosting a mirror with malicious intent then for 99% of the time I might run it by the book and very occasionally withold updates for a few hours in order to refresh my list of vulnerable clients. It would almost certainly pass unnoticed. Looking at the status list today I see that some of the Primary mirrors are on it including the one I use which has no local trace file (timestamp).

DNS Poisoning anyone ?
If the attackers can spoof the DNS of the repository mirror, then they can probably give you whatever they want.
It's a dangerous scenario.

With DNS spoofing they would still need to use packages with valid signatures, so a DNS-based attack wouldn't work - at least not on its own - since digital signatures make the source of the package irrelevant. The attack discussed in the article doesn't let the bad guys give you "whatever they want", it lets them give you vulnerable packages which have previously been signed by the distribution's maintainer. Or they can also just keep you on a certain version of a package (not necessarily vulnerable at the current time) while they sit and wait for a vulnerability to become known to them.

That's possible but more likely is witholding updated packages, as package managers by default don't install older packages in place of existsing ones, they upgrade to higher versions. You'd have to have been quite negligent in updating to be caught out by upgrading to a package with known vulnerabilities but it wouldn't be immediately obvious if a patch had been witheld in an otherwise normal looking transaction. When the next scheduled update is performed (maybe 24 hours later) everything is back to normal, all patches are applied, but by then an attacker has had his chance to install his modified binaries or extract data or whatever. Even if the user/admin becomes aware later of being compromised his chance of associating a publicly known exploit with somebody managing the mirror is far less likely than assuming it was done prior to the patch being rolled out at all. It would take some lateral thinking to even consider the idea, and good auditing, which may not be possible on a compromised machine, to verify. What are the chances that a lot of people would simply be unable to diagnose the whole scenario and would re-install using the exact same mirror?

btw the linked article is back up now.

Right, but you don't need to have them downgrade to feed them a vulnerable version. It can be the same idea as holding back, except you already know at which point to hold them back on. You hold back the patched version(s), thereby forcing the user to install the vulnerable version (which would still be a higher version than what he has).

Day 1: Distro foo 7.3 is released with package bar 1.0.

Day 2: Package bar 1.1 is released by the foo folks, addressing a critical security issue.

Day 3: Package bar 1.2 is released by the foo folks, addressing another critical security issue.

Day 4: User win32sux installs foo 7.3, and upon doing a package upgrade, gets upgraded to bar 1.1 by a rogue mirror. He is now vulnerable to the security issue addressed in bar 1.2, and the rogue mirror operator knows it. User win32sux's package manager has no way of knowing that the mirror is supposed to be giving him bar 1.2 - unless it has a way to get timely digitally signed information, right?

Yes, exactly it. Very neat isn't it?

Haha, interesting choice of words. :)

I'm thinking one thing that could be done is have distributions offer periodical timestamped package lists (digitally signed, of course). Say, maybe like 3 times a day or something. So, before downloading any packages, your package manager downloads and checks the timestamped package list, and rejects it if it has a timestamp older than 8 hours (it should probably then automatically try another mirror). If the timestamp is younger than 8 hours, it accepts it and proceeds to start downloading packages. So basically rogue mirror operators would only have 8-hour windows. Not sure if that makes sense or not.

Do you (or anyone else) have any ideas about a permanent solution to the holding back vulnerability which doesn't require direct communication with the distribution's servers?

I think the original article offered a range of solutions, the crucial one in this case being time expiry on signed metadata which at least reduces the window for attack. The best solution would seem to be to only update direct from the original distro repositories using https but that's likely to remain an option for commercial distros only. Perhaps package manager clients should always refer the signed metadata to the original distro repository via https to compare timestamps before accepting the mirror's version as valid? So not only is the metadata known to be good and within its expiry limit but is also proven to be the latest available (there may be times when a patch is pushed through in quick time). This might be a reasonable alternative to using https for the entire transaction which would be cost prohibitive for the mirrors.