[carlosponti]

Originally Posted by geniuz

I shouldn't worry about it to much, why would anybody want to spend time on infecting linux computers ? I don't know exact numbers, but I do believe very little people on this world actually use linux full time compared to the ones using Windows, and Windows as we all know is much easier to hack.

this is a fallacy, People who do this kind of stuff do so out of curiosity and that its there to be done. Not to mention statements like this make people curious to see if it is possible. Its often difficult to determine how many holes there are in source because of the sheer number of lines that potentially have problems. thought one of linux's strengths is in its patching ability being just plain faster than windows. Linux numbers are growing to a point where its getting attention. not to mention that Mac has about the same numbers and already has publish and "in the wild" vulnerabilities and virii for it as well. the Linux numbers game isn't one I would bet on anytime soon.

ps I would hope that soon distros put place safeguards from just anybody putting up a mirror, plus make sure that those mirrors keep track of how up to date the packages are.

[elija]

And then there is the kudos factor. Linux is more secure than Windows so cracking* it becomes a real challenge.


* I refuse to use the term hacking when I mean cyber-terrorism

[carlosponti]

Originally Posted by elija

And then there is the kudos factor. Linux is more secure than Windows so cracking* it becomes a real challenge.


* I refuse to use the term hacking when I mean cyber-terrorism

I have trouble using the word hacker as well because most who do this stuff don't understand what they are doing but find code online and use it just for kicks. Majority of the time kids who call themselves hackers are really script kiddies. the definition has changed so much the last few years.

[fingal]

The site's back up... looks like they have a point after all.

[Thrillhouse]

Originally Posted by smolloy

This isn't true. The authors of this paper showed how it was possible even with signed packages. It's called a replay attack. They set up a repo containing old versions of packages with known vulnerabilites. Since these were old, and therefore legitimate, versions of packages, they had the correct key. For example, someone could set up a repo to roll all debian machines back to the old, broken version of openssl. They'd then watch their logs to see which IP's had rolled back to the old version and then root them.

In this case, the vulnerability is not in the package manager. The vulnerability is in openssl. Or you could even argue the vulnerability is in the distro's policy of keeping out-of-date, insecure packages in the repos. Or the vulnerability is in the user who (assuming he set himself up to use the malicious "repo-in-the-middle") trusted the bad repo.

No matter which one you choose, the vulnerability is not in the package manager.

Signing doesn't help.

Of course it does. That's about the only thing that helps. Signing is the industry standard for trusting third parties. Trillions of dollars is transacted over the Internet every year on the foundation of signing and encryption technologies. If we can trust it for things of that level of importance, can't we also trust it to handle something as simple as package management?

Also, "every means possible" isn't true either. They were able to set up a repo for all major distros with no significant checking of their identity.

Again, this can be remedied with simple, but thorough, security practices, namely: signing.

This really is something to worry about, which is why I posted it here. There are ways to mitigate this, but it needs quick action from the distro maintainers. There's very little we can do about this ourselves.

Agreed. Since I actually got a chance to read the article now, I realize that most of their focus is on each distro's policies and practices, not necessarily on the package managers, themselves. The only real flaw they identified with the package managers is the lack of a verification process, which is the big problem that I think most people already realized. Talking about mirror control and maintaining flawed, out-of-date packages is all well and good (hopefully it will light a fire under the butts of some distro's developers) but it has little to do with the package managers, themselves.

A nice, elegant solution to this would be to set up some sort of centralized PKI (independent of distribution) which adopts distros and issues credentials for each one, and have all of the distros implement the security measures in their package managers. That way, if you have two distros based on the same package manager (e.g. Debian and Ubuntu), you're able to cross-verify repos and Ubuntu could install packages from the Debian repositories (or vice versa) and could do so without worrying about the real source of that package.

[elija]

Originally Posted by Thrillhouse

Of course it does. That's about the only thing that helps. Signing is the industry standard for trusting third parties. Trillions of dollars is transacted over the Internet every year on the foundation of signing and encryption technologies. If we can trust it for things of that level of importance, can't we also trust it to handle something as simple as package management?


Again, this can be remedied with simple, but thorough, security practices, namely: signing.

I think their point here is that signing won't help without thorough checks. A cert is given to a mirror and then that mirror is signed. It could still offer up old and known to be vulnerable packages.

But it's signed so we trust it...

Also who is to say that a "Mirror" can't get itself a certificate? A false company, a hired server and a thawte certificate. Easy peasy. I don't know if that is actually possible but getting a certificate isn't exactly difficult!

[Thrillhouse]

Originally Posted by elija

I think their point here is that signing won't help without thorough checks. A cert is given to a mirror and then that mirror is signed. It could still offer up old and known to be vulnerable packages.

But it's signed so we trust it...

Yes, that is their point and that's the point I made in my post. The only intrinsic vulnerability in most package managers is the lack of verification of packages. Everything else is security policy. Keeping out of date packages in the repos is a flaw in policy. Not providing mirror and metadata control is another flaw in policy.

Also who is to say that a "Mirror" can't get itself a certificate? A false company, a hired server and a thawte certificate. Easy peasy. I don't know if that is actually possible but getting a certificate isn't exactly difficult!

You're right. Getting your own certificate is extremely easy. Getting a trusted certificate, one that is issued by an authority, is not. That's why I proposed a PKI system for this problem. Certificates issued by a trusted CA are almost impossible to forge.

Let's say, starting tomorrow, Fedora was going to start implementing good security practices in their package manager by signing everything: packages, metadata, mirrors, etc. In order for people to verify the packages they download, though, the signing certificate has to be published. So, they put it up on their website and say "here it is, verify your packages against this." Well, who's to say their website hasn't been hacked and that the certificate they published is the real one? What if an attacker got in and published their own certificate? Then you have a problem. Do we really trust Fedora's servers to be that secure? We probably shouldn't. That's what public key infrastructure is for.

[smolloy]

Originally Posted by Thrillhouse

In this case, the vulnerability is not in the package manager. The vulnerability is in openssl. Or you could even argue the vulnerability is in the distro's policy of keeping out-of-date, insecure packages in the repos. Or the vulnerability is in the user who (assuming he set himself up to use the malicious "repo-in-the-middle") trusted the bad repo.

Yes, the vulnerability is with openssl, but it is the attack on the package management process that allows the old, vulnerable version of openssl to be installed. A replay attack such as this needs a hole in the package management system as well as a faulty, but previously legit, version of a package.

Originally Posted by Thrillhouse

No matter which one you choose, the vulnerability is not in the package manager.

I understand what you mean, but we're just playing with words now. The researchers figured out a way to subvert the package management to root your machine. If Internet Explorer allowed someone to roll back to a vulnerable version of flash in order to crack your machine you wouldn't argue that flash is vulnerable (since an updated version exists which is not vulnerable), but you would agree that IE needed patched. This is similar to what is happening here.

Vulnerable versions of many many packages exist out there, and they were all legitimately signed. The package management needs to support a method by which these packages cannot be rolled back to these dodgy versions.

Originally Posted by Thrillhouse

Of course it does. That's about the only thing that helps. Signing is the industry standard for trusting third parties. Trillions of dollars is transacted over the Internet every year on the foundation of signing and encryption technologies. If we can trust it for things of that level of importance, can't we also trust it to handle something as simple as package management?

No. Signing does not help this particular problem. The dodgy versions of the old packages are already signed. That is why this attack is possible. The signing just prevents unsigned malicious code from being installed -- it does not prevent old, already signed, vulnerable pieces of code from being installed.

I'm not saying that signing is bad, and you provide a good example of why it is so useful. All I'm saying is that signing doesn't help with this problem. We need another approach (as well as signing).

Originally Posted by Thrillhouse

Again, this can be remedied with simple, but thorough, security practices, namely: signing.

No. See my previous answer.

A solution I was thinking about would be for the package manager to check all visible repos for each package it wants to install. That way it can tell if a particular repo isn't as up to date as it should be, and ping a central server. If a repo gets enough pings it can be taken offline by a central system.

But having thorough verification of each new repo would really help!

[Jonathan183]

Originally Posted by Thrillhouse

Let's say, starting tomorrow, Fedora was going to start implementing good security practices in their package manager by signing everything: packages, metadata, mirrors, etc. In order for people to verify the packages they download, though, the signing certificate has to be published. So, they put it up on their website and say "here it is, verify your packages against this." Well, who's to say their website hasn't been hacked and that the certificate they published is the real one? What if an attacker got in and published their own certificate? Then you have a problem. Do we really trust Fedora's servers to be that secure? We probably shouldn't. That's what public key infrastructure is for.

At some point we need to trust some information we receive. If you trust the distro sufficiently to install the system is there any reason why you would not trust their servers?

Using a separate certifying authority just looks to creates a common point for all distros ... a real prize worth some time & effort to crack ?

[Agent-X]

I read about this over at linuxquestions.org but I still don't understand some aspects of it. For instance, if I'm getting my things from a debian server, and all I use is that official debian server, how exactly is something going to go wrong?

I mean, are all of you saying the debian.org website directs people to mirrors if it doesn't feel like sharing its bandwidth? Otherwise, I would think that debian has already checked the packages (to a degree) to make sure they are secure.

So, what is really going on?

Is this an issue where people are being redirected to mirrors with bad packages?