On 07 Nov 2004 16:28:04 +0100
Peter Simons <simons@cryp.to> wrote:
> Let me restate the problem in my own words. Anyone who has
> access to a Gentoo mirror can modify a crucial part of the
> build infrastructure to execute arbitrary code on my system
Just like anyone who has access to a KDE, GNU, kernel mirror or your ISPs
DNS or Proxy.
> and Gentoo does, as of now, provide no way for me to
> recognize this has happened.
"Manifest"s can be found in each package directory. Problem is, they come
from the same source as the files they are supposed to verify.
>
> You believe this is nothing more than FUD?
The problem is real, the way it was presented, including tone of language
and the "exploit" is spreading FUD.
>
> This problem has nothing to do with trusted or untrusted
> code, it is about data integrity.
This is exactly the same, at least in security terminology. Trust depends
on a person's moral and his or her technical capabilities.
In a security context, you cannot trust your best friend if he or she
lacks the ability to protect the data in question. A good example for this
are PGP/GPG trust levels. In order to deserve trust, a person
needs moral integrity AND a good understanding of public key encryption.
One virtue alone is useless.
The same is true for an operator of a mirror or a software developer.
>
> > (1) the server has not been compromised
>
> How do I very this?
Not at all. This is why you can *never* fully trust your source. You
cannot trust, that this mail was written by me. Even if I had signed it,
you'd still need to obtain my public key through a reliable channel.
> Is there a list of SHA1 hashes of all
> files /usr/portage is supposed to contain?
There are MD5 hashes in the Manifest files.
>
> How do I verify this? Are there plans to use a
> synchronization protocol that authenticates the peer to rule
> out man-in-the-middle attacks? This shouldn't really be a
> problem because rsync is readily available over SSH tunnels.
SSH is prone to man-in-the-middle attacks as well - unless you have
obtained the server's host key through a reliable channel.
> > (3) the server operator is trustworthy
> > (4) the person that originally created the software is trustworthy
> > (5) the server operator's are sufficiently skilled to protect the
> > software(6) the person that originally created the software is
> > suffciently skilled
> > to protect it
>
> None of these points are relevant for the problem we are
> talking about. If Gentoo provides proper means of
> authenticating the data I receive from the mirror, I don't
> _need_ to trust the mirror's operator.
Only point (3) and (5) can be solved by signatures.
A signature ensures, that the data you received is identical to the data
that was signed. If the data was already compromised when it was
signed, you gain nothing except a wrong feeling of security.
That was exactly my point. Signing protects against certain attacks.
Namely compromised mirrors and malicious mirror operators. Nothing more.
>
> The fact that other projects have the same problem doesn't
> mean that the problem shouldn't be fixed in Gentoo.
Fixing it at a high level is of limited value, if there are attack vectors
at lower levels. True security has to start at each developer's personal
system, next are development servers and project management, followed by
file mirrors. Only if those parts are secure, a distributors measures have
any true meaning.
>
>
> > You can verify the data, if:
> > (1) a person has digitally signed the data
>
> So why is the data apparently _not_ digitally signed then?
Because a signature alone is *completely* pointless, and the following
points are rather difficult to achieve.
>
>
> > (2) the person in (1) is trustworthy
> > (3) the person in (1) is suffciently skilled to judge the integrity
> > of data
> > (4) the person in (1) knows how to handle the keys safely
> > (5) the person in (1) has not been compromised
> > (6) you have a secure way to obtain that persons public key
> > (7) you know how to use digital signatures
>
> With (1) not being implemented, (2)-(7) are pretty much
> irrelevant right now, IMHO. Frankly, _this_ is FUD.
I was listing everything that is required. Every point has to be
fulfilled for digital signatures to be useful. If one single point is not
true, the signature is worthless.
> What does it matter whether the problem is specific to
> Gentoo or not?
Gentoo has to rely on the judgement of others. A trojan in the original
kernel sources, for example, would be happily signed by Fedora, Suse,
Debian or Gentoo.
> So how long will it (approximately) take until this problem
> is fixed?
It will probably never be fixed completely. Gentoo has basically done its
part. See
http://www.gentoo.org/news/20041021-portage51.xml One big problem with signatures is secure key exchange. This has to happen
inside the Gentoo project and between the project and its users. Both
cases are difficult.
The further problem is responsibility. A source package on an external
project's server is trojaned. A Gentoo developer signs the ebuild and
the source code. The trojan is discovered. Now, what should happen?
The developer has claimed implicitly, through his signature, that the
package is correct.
What do you do? Call the developer a liar, just lazy, or do you even
understand and accept the situation?
In any case, you can no longer trust this developers signature, in fact
you
never could.
> > So a signed Portage tree might improve security, but only
> > against one of many risks.
>
> One risk less to worry about.
But a lot of risks remaining. When diving through a swarm of sharks I
wouldn't worry about the risks of car traffic. Still I would not feel
secure.
Regards
BTW: Don't get me wrong. I am not against the usage of signatures in
Gentoo. However, I'm not sure if the, IMHO rather small, security gain is
truly worth the effort and the possible social consequences (What happens
to a developer who accidently signed a trojaned package or who lost
her/his key?).
--
gentoo-security@gentoo.org mailing list
