| 1 |
Marc Ballarin writes: |
| 2 |
|
| 3 |
> Sorry if this sounds harsh, but calling this an exploit |
| 4 |
> is ridiculous. [...] As it stands, it is plain FUD. |
| 5 |
|
| 6 |
Let me restate the problem in my own words. Anyone who has |
| 7 |
access to a Gentoo mirror can modify a crucial part of the |
| 8 |
build infrastructure to execute arbitrary code on my system |
| 9 |
and Gentoo does, as of now, provide no way for me to |
| 10 |
recognize this has happened. |
| 11 |
|
| 12 |
You believe this is nothing more than FUD? |
| 13 |
|
| 14 |
|
| 15 |
> If you download and execute untrusted code you are in |
| 16 |
> danger. |
| 17 |
|
| 18 |
This problem has nothing to do with trusted or untrusted |
| 19 |
code, it is about data integrity. Or, more accurately, about |
| 20 |
_lack_ thereof. |
| 21 |
|
| 22 |
|
| 23 |
> (1) the server has not been compromised |
| 24 |
|
| 25 |
How do I very this? Is there a list of SHA1 hashes of all |
| 26 |
files /usr/portage is supposed to contain? |
| 27 |
|
| 28 |
|
| 29 |
> (2) your connection has not been compromised |
| 30 |
|
| 31 |
How do I verify this? Are there plans to use a |
| 32 |
synchronization protocol that authenticates the peer to rule |
| 33 |
out man-in-the-middle attacks? This shouldn't really be a |
| 34 |
problem because rsync is readily available over SSH tunnels. |
| 35 |
|
| 36 |
|
| 37 |
> (3) the server operator is trustworthy |
| 38 |
> (4) the person that originally created the software is trustworthy |
| 39 |
> (5) the server operator's are sufficiently skilled to protect the software |
| 40 |
> (6) the person that originally created the software is suffciently skilled |
| 41 |
> to protect it |
| 42 |
|
| 43 |
None of these points are relevant for the problem we are |
| 44 |
talking about. If Gentoo provides proper means of |
| 45 |
authenticating the data I receive from the mirror, I don't |
| 46 |
_need_ to trust the mirror's operator. |
| 47 |
|
| 48 |
|
| 49 |
> However, none of those issues is specific to Gentoo or |
| 50 |
> Open Source as a whole. |
| 51 |
|
| 52 |
The fact that other projects have the same problem doesn't |
| 53 |
mean that the problem shouldn't be fixed in Gentoo. |
| 54 |
|
| 55 |
|
| 56 |
> You can verify the data, if: |
| 57 |
> (1) a person has digitally signed the data |
| 58 |
|
| 59 |
So why is the data apparently _not_ digitally signed then? |
| 60 |
|
| 61 |
|
| 62 |
> (2) the person in (1) is trustworthy |
| 63 |
> (3) the person in (1) is suffciently skilled to judge the integrity of |
| 64 |
> data |
| 65 |
> (4) the person in (1) knows how to handle the keys safely |
| 66 |
> (5) the person in (1) has not been compromised |
| 67 |
> (6) you have a secure way to obtain that persons public key |
| 68 |
> (7) you know how to use digital signatures |
| 69 |
|
| 70 |
With (1) not being implemented, (2)-(7) are pretty much |
| 71 |
irrelevant right now, IMHO. Frankly, _this_ is FUD. |
| 72 |
|
| 73 |
|
| 74 |
>> (1) Do you agree that this is a problem? |
| 75 |
|
| 76 |
> Of course. It is just in *no* way specific to Gentoo. |
| 77 |
|
| 78 |
What does it matter whether the problem is specific to |
| 79 |
Gentoo or not? |
| 80 |
|
| 81 |
|
| 82 |
>> (3) Is there any estimate how long [fixing this problem] |
| 83 |
>> will take? |
| 84 |
|
| 85 |
> IMO the purely technical issues have been solved mostly. |
| 86 |
> However, those are smallest and least important part. |
| 87 |
|
| 88 |
So how long will it (approximately) take until this problem |
| 89 |
is fixed? |
| 90 |
|
| 91 |
|
| 92 |
> Remember: All that Gentoo can protect against are |
| 93 |
> attempts to manipulate data on Gentoo's rsync or file |
| 94 |
> mirrors from the outside. Nothing more. |
| 95 |
|
| 96 |
Then why doesn't Gentoo _do_ that? |
| 97 |
|
| 98 |
|
| 99 |
> So a signed Portage tree might improve security, but only |
| 100 |
> against one of many risks. |
| 101 |
|
| 102 |
One risk less to worry about. |
| 103 |
|
| 104 |
Peter |
| 105 |
|
| 106 |
-- |
| 107 |
gentoo-security@g.o mailing list |
Archives