[elija]

I think it's more a case of people choosing a mirror that has been officially approved with minimal checks. The mirror then servers up dodgy old packages.

[smolloy]

Originally Posted by elija

I think it's more a case of people choosing a mirror that has been officially approved with minimal checks. The mirror then servers up dodgy old packages.

That's precisely what it is.

The packages are official and legit (that's why they are signed), but they're old. So the risk is that someone sets up a legitimate looking mirror that serves up old packages with known weaknesses.

[Thrillhouse]

So, it didn't take long for this vulnerability to (almost) get exploited.

Online intruders hit Red Hat, Fedora Project

While I still don't agree that the package mangers, themselves, are to blame (does somebody want to explain to me why it's yum's fault that somebody hacked fedora's servers?) this does go to show what needs to be done.

I don't mean to brag but if they were using my idea, it would be a lot easier for them to recover from this break-in. Just revoke the current cert, re-issue, have all of the mirrors pluck the new cert off of an LDAP server and re-sign.

[smolloy]

Hi Thrillhouse,
I don't think the recent Redhat break-in is an example of the weakness we were discussing in this thread. The Redhat attack was a bunch of crooks hacking into a server to try to get at the key, whereas the vulnerability we were talking about was a bunch of crooks setting up their own repository with a legitimate key and then serving up old, signed, known-to-be-vulnerable packages.

The former (as you say) doesn't demonstrate a weakness in the package management system, while the latter does.

[Thrillhouse]

Originally Posted by smolloy

...whereas the vulnerability we were talking about was a bunch of crooks setting up their own repository with a legitimate key and then serving up old, signed, known-to-be-vulnerable packages.

Isn't it reasonable to assume that is exactly what they would have done had they learned the passphrase to the signing key? Heck, they wouldn't even need to set up their own mirror. They could probably carry it out on Fedora's servers.

In this case, the threat is more serious than the attack described in the paper because, even with signature verification, there would be no way to prevent a replay attack. The key would have been compromised and the attackers would essentially have total control while unwitting users download and install the vulnerable packages.

[smolloy]

True. That's probably what they were planning to do.

But, if they had have been successful, then they would have had a means to send out bad packages, just like the replay attack. So, from a users point of view, it would have been just as serious.

For what it's worth, I think the attack we were discussing is more serious since it shows that the managers of the repositories of all the major distros weren't as paranoid as I hoped they would be when it comes to allowing people to start their own repos. I think this is much more scary than the fact that there are crooks out there trying to hack into repo servers (which I assumed was happening anyway). Just my opinion.

[Thrillhouse]

Originally Posted by smolloy

For what it's worth, I think the attack we were discussing is more serious since it shows that the managers of the repositories of all the major distros weren't as paranoid as I hoped they would be when it comes to allowing people to start their own repos. I think this is much more scary than the fact that there are crooks out there trying to hack into repo servers (which I assumed was happening anyway). Just my opinion.

Exactly. That is part of the original point I was trying to make. It's not so much yum's fault that the packages it's fetching are out of date and/or insecure. That could (and probably should) be blamed on the repo maintainer. If the Fedora project doesn't force its volunteer mirrors to update flawed packages, that's a flaw in policy. They should have some kind of "3 strikes and you're out" policy where if you're a mirror and it's discovered you're keeping insecure packages out there when you've been told not to, you get a warning. If you don't pull the package after a certain period of time, that's one strike. Three strikes and you're blacklisted.

[smolloy]

Originally Posted by Thrillhouse

Exactly. That is part of the original point I was trying to make. It's not so much yum's fault that the packages it's fetching are out of date and/or insecure. That could (and probably should) be blamed on the repo maintainer. If the Fedora project doesn't force its volunteer mirrors to update flawed packages, that's a flaw in policy. They should have some kind of "3 strikes and you're out" policy where if you're a mirror and it's discovered you're keeping insecure packages out there when you've been told not to, you get a warning. If you don't pull the package after a certain period of time, that's one strike. Three strikes and you're blacklisted.

I couldn't agree more

I like the idea of updating yum/apt/yast/etc to look at several repos, and compare the version numbers. If it finds a repo with a lower version number for a certain package than the rest, then it should ping the central server with its details. After a certain number of pings, that repo should be shut down and investigated.

[Thrillhouse]

Originally Posted by smolloy

I like the idea of updating yum/apt/yast/etc to look at several repos, and compare the version numbers. If it finds a repo with a lower version number for a certain package than the rest, then it should ping the central server with its details. After a certain number of pings, that repo should be shut down and investigated.

That's a good idea but how would you go about shutting down the repo? For the bigger distros, most of these mirrors are outside of the control of the project. They rely on the benevolence of other organizations, like universities, to distribute software. And if it is a malicious attacker, they're not likely to shut it down just because you asked them to. So, what do you do? Run a reciprocal DOS attack on the offending party? Sounds fishy. I suppose you could write something into the package manager that deletes the repo from your sources.list (if you're .deb) or /etc/yum.repos.d (for yum) but that could possibly open up another security hole.

I think the best you can do is announce that said repo is untrusted and put the onus on the user to go about removing it.

[smolloy]

Could you have a blacklisted file in yum.repos.d? "Bad" repos could be added to that on yum updates, and yum will only ever download that particular file from a central redhat server.

Something still doesn't feel right about this though. It's quite a hard problem to solve, which is why I worry about it.