1 |
On Wed, Feb 18, 2004 at 02:13:37AM -0500, Ed Grimm wrote: |
2 |
> |
3 |
> And how do you know the published hash? Are there not entities in the |
4 |
> datastream that could alter both the file you download and the MD5 that |
5 |
> you download? Especially if, as I think I've seen, emerge gets the MD5 |
6 |
> hash from the same source as it gets the source packages. However, even |
7 |
> in the case of multiple mirrors, either the primary FTP server could've |
8 |
> been cracked, or the datastream could be hijacked at the local ISP, |
9 |
> inserting an altered datasream for each file. |
10 |
|
11 |
I don't think _your_ portage gets the MD5 and package from the same source. |
12 |
I don't know how the MD5 gets into the ebuild (see my last paragraph), |
13 |
but I think the MD5 that gets used when you execute emerge -u xyzzy is |
14 |
not collected at the same time as the source package. |
15 |
|
16 |
I thought portage worked like this: |
17 |
|
18 |
emerge sync: |
19 |
- get some sort of pointer to other sites from master site |
20 |
- rsync portage tree from the pointed site |
21 |
now, portage tree contains info about builds AND MD5 HASHES |
22 |
|
23 |
emerge -u xyzzy: |
24 |
- get source package from actual distributor, NOT GENTOO |
25 |
- compare MD5 of that to MD5 hash in portage tree |
26 |
- continue ebuild |
27 |
|
28 |
So, the MD5 hash in the portage tree comes from a different server |
29 |
than the source package. So, the determined attacker would have to |
30 |
control considerable more than one site. If our hero doesn't |
31 |
perform the sync and update close together in time, then the attacker |
32 |
has to control the external network for a long time as well. |
33 |
|
34 |
|
35 |
I have a separate concern. I haven't read enough to know the |
36 |
process by which ebuilds get committed to the portage tree. |
37 |
If the submitter of the ebuild downloads the source and generates |
38 |
the MD5 hash from the package, then all an attacker has to do |
39 |
to compromise all gentoo distributions that use the package is |
40 |
to control the distribution site from the time when the ebuild |
41 |
is created until the desired number of sites are affected. For things |
42 |
like the gnu sources (for example), there are enough mirrors that |
43 |
an ebuild submitter could get the source from a few different mirrors, |
44 |
verify that they are all hash identical (or better yet binary |
45 |
identical), then add that hash to the ebuild. For smaller, non- |
46 |
mirrored packages the trust model is shakier. Does anyone know |
47 |
the process by which ebuilds are committed? |
48 |
|
49 |
-wmr- |
50 |
|
51 |
-- |
52 |
gentoo-security@g.o mailing list |