1 |
On 07 Nov 2004 16:28:04 +0100 |
2 |
Peter Simons <simons@××××.to> wrote: |
3 |
|
4 |
> Let me restate the problem in my own words. Anyone who has |
5 |
> access to a Gentoo mirror can modify a crucial part of the |
6 |
> build infrastructure to execute arbitrary code on my system |
7 |
|
8 |
Just like anyone who has access to a KDE, GNU, kernel mirror or your ISPs |
9 |
DNS or Proxy. |
10 |
|
11 |
> and Gentoo does, as of now, provide no way for me to |
12 |
> recognize this has happened. |
13 |
|
14 |
"Manifest"s can be found in each package directory. Problem is, they come |
15 |
from the same source as the files they are supposed to verify. |
16 |
|
17 |
> |
18 |
> You believe this is nothing more than FUD? |
19 |
|
20 |
The problem is real, the way it was presented, including tone of language |
21 |
and the "exploit" is spreading FUD. |
22 |
|
23 |
> |
24 |
> This problem has nothing to do with trusted or untrusted |
25 |
> code, it is about data integrity. |
26 |
|
27 |
This is exactly the same, at least in security terminology. Trust depends |
28 |
on a person's moral and his or her technical capabilities. |
29 |
In a security context, you cannot trust your best friend if he or she |
30 |
lacks the ability to protect the data in question. A good example for this |
31 |
are PGP/GPG trust levels. In order to deserve trust, a person |
32 |
needs moral integrity AND a good understanding of public key encryption. |
33 |
One virtue alone is useless. |
34 |
The same is true for an operator of a mirror or a software developer. |
35 |
|
36 |
> |
37 |
> > (1) the server has not been compromised |
38 |
> |
39 |
> How do I very this? |
40 |
|
41 |
Not at all. This is why you can *never* fully trust your source. You |
42 |
cannot trust, that this mail was written by me. Even if I had signed it, |
43 |
you'd still need to obtain my public key through a reliable channel. |
44 |
|
45 |
> Is there a list of SHA1 hashes of all |
46 |
> files /usr/portage is supposed to contain? |
47 |
|
48 |
There are MD5 hashes in the Manifest files. |
49 |
|
50 |
> |
51 |
> How do I verify this? Are there plans to use a |
52 |
> synchronization protocol that authenticates the peer to rule |
53 |
> out man-in-the-middle attacks? This shouldn't really be a |
54 |
> problem because rsync is readily available over SSH tunnels. |
55 |
|
56 |
SSH is prone to man-in-the-middle attacks as well - unless you have |
57 |
obtained the server's host key through a reliable channel. |
58 |
|
59 |
> > (3) the server operator is trustworthy |
60 |
> > (4) the person that originally created the software is trustworthy |
61 |
> > (5) the server operator's are sufficiently skilled to protect the |
62 |
> > software(6) the person that originally created the software is |
63 |
> > suffciently skilled |
64 |
> > to protect it |
65 |
> |
66 |
> None of these points are relevant for the problem we are |
67 |
> talking about. If Gentoo provides proper means of |
68 |
> authenticating the data I receive from the mirror, I don't |
69 |
> _need_ to trust the mirror's operator. |
70 |
|
71 |
Only point (3) and (5) can be solved by signatures. |
72 |
A signature ensures, that the data you received is identical to the data |
73 |
that was signed. If the data was already compromised when it was |
74 |
signed, you gain nothing except a wrong feeling of security. |
75 |
|
76 |
That was exactly my point. Signing protects against certain attacks. |
77 |
Namely compromised mirrors and malicious mirror operators. Nothing more. |
78 |
|
79 |
> |
80 |
> The fact that other projects have the same problem doesn't |
81 |
> mean that the problem shouldn't be fixed in Gentoo. |
82 |
|
83 |
Fixing it at a high level is of limited value, if there are attack vectors |
84 |
at lower levels. True security has to start at each developer's personal |
85 |
system, next are development servers and project management, followed by |
86 |
file mirrors. Only if those parts are secure, a distributors measures have |
87 |
any true meaning. |
88 |
|
89 |
> |
90 |
> |
91 |
> > You can verify the data, if: |
92 |
> > (1) a person has digitally signed the data |
93 |
> |
94 |
> So why is the data apparently _not_ digitally signed then? |
95 |
|
96 |
Because a signature alone is *completely* pointless, and the following |
97 |
points are rather difficult to achieve. |
98 |
|
99 |
> |
100 |
> |
101 |
> > (2) the person in (1) is trustworthy |
102 |
> > (3) the person in (1) is suffciently skilled to judge the integrity |
103 |
> > of data |
104 |
> > (4) the person in (1) knows how to handle the keys safely |
105 |
> > (5) the person in (1) has not been compromised |
106 |
> > (6) you have a secure way to obtain that persons public key |
107 |
> > (7) you know how to use digital signatures |
108 |
> |
109 |
> With (1) not being implemented, (2)-(7) are pretty much |
110 |
> irrelevant right now, IMHO. Frankly, _this_ is FUD. |
111 |
|
112 |
I was listing everything that is required. Every point has to be |
113 |
fulfilled for digital signatures to be useful. If one single point is not |
114 |
true, the signature is worthless. |
115 |
|
116 |
> What does it matter whether the problem is specific to |
117 |
> Gentoo or not? |
118 |
|
119 |
Gentoo has to rely on the judgement of others. A trojan in the original |
120 |
kernel sources, for example, would be happily signed by Fedora, Suse, |
121 |
Debian or Gentoo. |
122 |
|
123 |
> So how long will it (approximately) take until this problem |
124 |
> is fixed? |
125 |
|
126 |
It will probably never be fixed completely. Gentoo has basically done its |
127 |
part. See http://www.gentoo.org/news/20041021-portage51.xml |
128 |
|
129 |
One big problem with signatures is secure key exchange. This has to happen |
130 |
inside the Gentoo project and between the project and its users. Both |
131 |
cases are difficult. |
132 |
The further problem is responsibility. A source package on an external |
133 |
project's server is trojaned. A Gentoo developer signs the ebuild and |
134 |
the source code. The trojan is discovered. Now, what should happen? |
135 |
The developer has claimed implicitly, through his signature, that the |
136 |
package is correct. |
137 |
What do you do? Call the developer a liar, just lazy, or do you even |
138 |
understand and accept the situation? |
139 |
In any case, you can no longer trust this developers signature, in fact |
140 |
you |
141 |
never could. |
142 |
|
143 |
> > So a signed Portage tree might improve security, but only |
144 |
> > against one of many risks. |
145 |
> |
146 |
> One risk less to worry about. |
147 |
|
148 |
But a lot of risks remaining. When diving through a swarm of sharks I |
149 |
wouldn't worry about the risks of car traffic. Still I would not feel |
150 |
secure. |
151 |
|
152 |
Regards |
153 |
|
154 |
BTW: Don't get me wrong. I am not against the usage of signatures in |
155 |
Gentoo. However, I'm not sure if the, IMHO rather small, security gain is |
156 |
truly worth the effort and the possible social consequences (What happens |
157 |
to a developer who accidently signed a trojaned package or who lost |
158 |
her/his key?). |
159 |
|
160 |
-- |
161 |
gentoo-security@g.o mailing list |