Package manager vulnerabilities

Just something to think about:

http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html

I'm actually a bit surprised that stuff like this is so rampant. What's to lose by doing updates over HTTPS?

 

Did you happen to get that from Chris Thompson's Twitter? He just tweeted that to me earlier.

https://bugs.launchpad.net/ubuntu/ bug/1186793

Feel free to comment on the bug.

 

Actually I noticed your retweat of it, and figured it could do with posting here. Every once in a while we Linux users need our world shaken a little.

(And I should really set up a twitter account.)

 

How would SSL help, as in the article, they need to become a recognised mirror, so even with SSL the user could still get potentionally malicous packages ?

The attack seems quite convoluted.
How do you get the package manager to [semi] automatically downgrade to (vulnerable) older versions of the packages ?

How do you get around distros like Ubuntu and Debian ONLY distribute security updates to stable releases via a main security server than mirrors ?

The issue was raised in launchpad and fixed years ago, your bug is a duplicate.

In Ubuntu the release files expire, preventing the replay attack happening.

Cheers, Nick

 

No, the bug isn't a duplicate. I'm requesting HTTPS, which still isn't implemented.

Like the bug says:

The only thing the bug attempted to solve was replay attacks. The link was purely to show best practice, and what happens when you leave doors open.

 

1) How does that lead to a compromised system ?

2) If the signing key is compromised, HTTPS still leaves the package distribution process vulnerable. Dodgy packages can be signed and distributed. HTTPS won't prevent dodgy mirrors.

BTW Ubuntu signs with SHA256, not MD5.

Cheers, Nick

 

The same way an information leak for ASLR causes a compromised system. On its own more information for an attacker isn't going to take over a system, but it is going to provide them with the means to do so.

An attacker can see what programs are being updated on a system.

HTTPS is only meant to prevent attacks that use MITM, not compromised mirrors. If the signing key is compromised that's separate from the package distribution process.

Ubuntu does, but it's not forced for third party devs. Regardless, collisions against MD5 didn't exist until they did. We're years off from a SHA collision, but it's called defense in depth. Ubuntu wants to be taken seriously, even for servers, and they should pick up the security slack.

Basically, like the bug says:

1) Not using HTTPS provides information to an attacker about local services running, versions, programs installed, update frequency, etc. Lots of information, especially valuable for targeted attacks.

2) In the case of MITM, when the signature is compromised, collided, or otherwise bypassed, an attacker can now install updates on the users machine with their own payloads. Just like Flame did. And "innocent" users, who weren't the end targets, got infected.

The solution is for Canonical to implement HTTPS and for them to encourage third parties to do the same.