|
Description
To solve the potential problem of malicious repositories
(repositories advertised online contain malicious packages. Users add these repositories to their source-list and get infected with the malware in these repositories/out of date repositories like the "attacks on package managers" by the university of arizona):
Add a blacklist to apt where known malicious repositories can be blocked.
The list is kept up-to-date by regular updates.
This is a fix. Not a solution.
Important: The ubuntu repositories must not be blocked (or it would lead to a update-dos)
Attachments
No attachments.
Duplicates
Comments
|
Auzy wrote on the 15 Jul 08 at 12:05
|
I'm afraid I have to -1. Its not that its a bad idea, I don't feel its a good way of implementing it.
The best way of implementing this would be via digital certificates. All packages in the repos should be digitally signed by the packager (so Ubuntu packagers should sign them as owning to canonical). That means anyone could distribute the packages, and it would be ok.
Then we can unsigned packages, or ones not signed by Canonical.
|
|
Sidney wrote on the 15 Jul 08 at 15:09
|
Well, the only person who can "install" new repos is root. Also, the only person to edit the blacklist is root. Plus normally you shouldn't add repos frequently, if at all.
So nothing is gained with this idea: Root finds a new repo that he likes. He goes and adds it into sources.lst. But now the blacklist vetoes package installs from there. The usual consequence would be that root disables the blacklist, because he explicitely wanted the new repo.
The only advantage of a repo blacklist is a system where all users can add repos. And if you allow that, you probably have worse problems. ;-)
|
|
gmatht wrote on the 15 Jul 08 at 16:15
| |
A "warning, this repo is known to be malware" might help a few people. (Ofcourse, then the bad guys would move the repo somewhere else)
|
|
Vadim P. wrote on the 15 Jul 08 at 20:08
|
I don't feel there is a good way to control this available yet, and the warnings aren't a good idea either.
If it's a malware PPA repository, you can report it right away though.
|
|
andruk wrote on the 15 Jul 08 at 20:46
|
The full article is here: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-packa ge-managers.html
Let me attempt to explain it a bit.
The issue is that an organization can keep a mirror of repositories until they get a number of regular users using their repository. Then, when an exploit comes out, they don't update their repository (before people start to notice), and when clients download the package list, the organization knows that the clients are using exploitable versions, and can automate an attack on the user's systems (see the recent Debian-and-derivatives OpenSSH vulnerability).
This would be difficult to prevent with any sort of signage, as the malicious repo would be hosting a signed package list, but the package list could be maliciously outdated. Until somebody notices that the mirror is outdated, they won't have to update their package list.
The organization could even regularly delay updates, and gradually infect systems until they were discovered.
The only way I can think of to fix this is to
1) (on the client side) randomize the mirror to download the package list from (lessens the chance of an out-of-date mirror, but doesn't completely solve the problem - what happens when an unlucky client downloads from a bad repo and gets auto-infected?)
2) (on the client side) download package lists from two different (random) mirrors and compare them (lessens the chance that a downloaded package list is out-of-date, but does not eliminate it - what happens if there are 15 malicious servers with the same out-of-date package list?)
3) download a package list from a mirror and hash it, and download a hash of the most recent package list from "official" servers (Canonicals, or anybody that is trusted),and compare the two. If the hashes don't match, it downloads the package list from a different mirror until it gets a completely up-to-date package list. (This solves the problem completely, but imposes another small task on the "official"-or-trusted servers)
The root of the problem is that mirror repos aren't investigated thoroughly enough, so just about anybody can host an "official" mirror of a repo. Presumably, in-depth investigations of everybody that wants to mirror a repo are not economical.
I hope this clears up any confusion...
I don't know how to vote on this idea, its aim is a good one, but blacklists/whitelists should be a last resort (as you are always playing catch-up with the latest malicious/benign servers).
+0, good goal, poor implementation
|
|
Thorsten Sick wrote on the 16 Jul 08 at 17:51
|
This is not meant as a solution for the mirror problem but a workaround/emergency-off-switch or something like that.
A solution would be more like the point three in your list:
- Download hash of the package list from a ubuntu server
- Download package list from a mirror
- hash package list
- compare hashes
- if hashes match, download non-security packages from the mirror (if they do not match choose a different mirror or the ubuntu server)
- download packages with security fixes from certified ubuntu servers only
This would prevent both attacks with delayed mirrors:
- Delay updates to have outdated clients
- Wait for client that downloads a security fix and attack this while the client updates it's system
But this approach is a bit to difficult to implement and _test_ fast. And it would produce quite some load on ubuntu update servers.
|
|
andruk wrote on the 18 Jul 08 at 03:01
|
Thorsten Sick, yeah, I kept thinking about this, and came back to post just that. My solution is not a security fix, as the malicious server could still automate an exploit a client when the out-of-date package list is downloaded to the client.
It seems that packages with security fixes need to be downloaded from a _well-certified_ Ubuntu servers.
|
Post your comment
|
