On 07 Nov 2004 14:14:28 +0100
Peter Simons <simons@...> wrote:

> Fellow Gentoo'ers,
> 
> I have to say that I am shocked by Alexander's posting. Once
> more I am forced to recognize that there is a difference
> between knowing that an exploit is "theoretically possible"
> and _seeing_ the actual exploit implemented in under 50
> lines of code.

Sorry if this sounds harsh, but calling this an exploit is ridiculous. If
this is an exploit, this is as well: "rm -rf /"
Just hack a portage mirror, and add it to some script...
As it stands, it is plain FUD.

If you download and execute untrusted code you are in danger. This
hopefully is common knowledge.
Wether you download an ISO-image, an update for Windows or a Portage tree
doesn't matter (not to mention the issue of malicous data, that can
exploit weaknesses in software...).

Either you can trust the source or you have to verify the data.

You can trust the source, if you know that:
(1) the server has not been compromised
(2) your connection has not been compromised (this includes routers, dns,
proxies, local lan, your local machine)
(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

In the case of Gentoo there are risks mainly at 1 and 5, additionally at
2 and maybe 3.
5 and especially 6 are general problems of open source

However, none of those issues is specific to Gentoo or Open Source as a
whole. This is just the nature of a public network.

You can verify the data, if:
(1) a person has digitally signed the data
(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

In case of Gentoo 1 is easy. 2 as well; if you don't trust the developers
you should not be using Gentoo.
3 is plain impossible. There is no possibility of a complete code
review. No distributor can do this, so it comes down to the reliability
of the individual open source projects. The person who signs the files has
to trust the original authors of the software.
4 is already difficult. If you have to sign a lot of files each day
you become sloppy. This is almost unavoidable.
>From an abstracted POV, a public key is just data. So for 6, we are back
to "You can trust the source, if:"...

> 
> Having said that, I am even more shocked by the fact that
> this problem has been long known! As a user who doesn't like
> the idea of giving up control of his machines to random
> people on the Internet, I would kindly request a statement
> from the Gentoo developers about this. Specifically:
> 

Well, I am no developer, but:
>  (1) Do you agree that this is a problem?

Of course. It is just in *no* way specific to Gentoo. rsync mirrors can be
compromised, but so does kernel.org, microsoft.com or any other server.
Digital signatures aren't used very often, because they are rather
difficult to handle, and can only solve the problem at one level.

> 
>  (2) Are there plans for getting it fixed?

Ther first step were those "Manifest" files, the second step were signed
Manifest files. See the portage-2.0.51 announcement.

> 
>  (3) Is there any estimate how long this will take?

IMO the purely technical issues have been solved mostly. However, those
are smallest and least important part.

Remember: All that Gentoo can protect against are attempts to manipulate
data on Gentoo's rsync or file mirrors from the outside. Nothing more.
They can't protect you from a poorly managed and compromised open source
project, from a malicious developer in- or outside Gentoo, from a
developer's compromised machine in- or outside Gentoo or from your own
mistakes.
So a signed Portage tree might improve security, but only against one of
many risks.

Regards

--
gentoo-security@g.o mailing list