Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 152977 - Lack of robustness against hacked rsync mirrors
Summary: Lack of robustness against hacked rsync mirrors
Status: RESOLVED DUPLICATE of bug 130039
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-27 07:23 UTC by CPUShare
Modified: 2011-10-30 22:40 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description CPUShare 2006-10-27 07:23:52 UTC
Hello,

This is just a preventive security bugreport.

Most distributions and package managers out there based on rpm are properly using cryptographic signatures to ensure that if a random mirror get hacked you won't risk anything. AFAICS this isn't the case with gentoo, if one of the rsync servers would get hacked lots of people could be affected without noticing. This is bad not just for gentoo but for Linux as a whole.

Luckily it's easy to fix without having to change much. The very simple change that I'm proposing will allow you to claim that next time a gentoo mirror get hacked no user with this feature enabled will risk to get hacked.

This is an independent feature compared to what's already available in form of FEATURES="gpg strict". "gpg strict" is very slow and only a few of the packages have been signed and not all files are being checked for coherency. Furthermore I want the signature checking to happen only in the background after the emerge --sync and never again (no like with "gpg strict") to avoid slowing down operation. And I want to be notified if one of which mirror has been hacked, so if enough people will enable the feature a mirror hack will be noticed immediately. Furthermore this way I can start using the more exotic local mirrors like rsync.country.gentoo.org that I currently have an hard time to trust, because I don't know how many people are using them (which means an hack may go unnoticed for a longer time than for a core mirror with tons of people using it). So this feature may lower the overall network load because any "untrusted" mirror may be trusted.

So my suggestion is to add something like this:

cd /usr/portage && find ! -type d | egrep -v '\./distfiles|\.packages|metadata/portage.md5' |sort | xargs tar c | md5sum | gpg --clearsign - > metadata/portage.md5

just before pushing out to the rsync. The above is a 1 minute hack, it probably can be improved, the file shouldn't have the "-" for example, but you get the idea how simple and how important this small change is.

The above is more than enough to later write a proper emerge --sync modification that will ensure the mirror data wasn't altered. The code that will verify signature and checksum is not a real concern (I could script it outside emerge initially), adding the feature to the server side is the only thing that matters in the short term. BTW, once we integrate the check into "emerge --sync", one option to add as well to rsync is --omit-dir-times, it's really pointless to care about the directory times and that saves some I/O.

Hope I didn't miss anything obvious, I did some search but I didn't find anything, though I'd be glad if this feature was already available and I overlooked it ;)

Thanks.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-10-27 07:47:06 UTC

*** This bug has been marked as a duplicate of 62642 ***
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-10-27 08:07:07 UTC
Eh, wrong bug #, anyway, filing bugs about this won't move thing an inch further.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-10-27 08:07:19 UTC

*** This bug has been marked as a duplicate of 130039 ***
Comment 4 CPUShare 2006-10-27 08:50:44 UTC
> filing bugs about this won't move thing an inch further.

So what would move this an inch further?

The bug you duplicated initially starts on the same problem but then focuses on the websync.

I'm interested to implement a solution to secure rsync, I'd like to avoid using the websync if possible.

Leaving the rsync mirrors going this way, with practically no way to reliably detect an exploit seems quite unprofessional regardless of the websync.