Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Security

Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo security RSS feed   Index | Next | Previous | View Threaded


simons at cryp

Nov 7, 2004, 6:14 AM

Post #1 of 27 (2266 views)
Permalink
Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

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.

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:

(1) Do you agree that this is a problem?

(2) Are there plans for getting it fixed?

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

I have read some of the material Alexander hyper-linked to
and, frankly, most of it is outright frightening.


> PPPS: I really appreciate all the very good work on
> hardened gcc, selinux-profiles and so on, but for me,
> this all seems useless as long as the base is compromised
> that easy and the user has no practical way (e.g. hashs)
> to check what he gets on his machine with a 'sync'.

I wholeheartedly agree.

Peter


--
gentoo-security [at] gentoo mailing list


klausman at schwarzvogel

Nov 7, 2004, 8:15 AM

Post #2 of 27 (2223 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

Hi!

On Sun, 07 Nov 2004, Marc Ballarin wrote:
[... many valid points ...]
> So a signed Portage tree might improve security, but only against one of
> many risks.

Which should in no way keep us from trying to plug the specific
hole. Gotta start *somewhere*. It's not like Gentoo is a bad
distro security-wise (as some seem to think), nor is it secure
enough to just do nothing. Truth's somewhere inbetween.

Greets,
Tobias

--
export DISPLAY=vt100

--
gentoo-security [at] gentoo mailing list


alex at ssji

Nov 7, 2004, 8:20 AM

Post #3 of 27 (2219 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

Just a question : could it be a good idea to move md5 on another server
or to do 'emerge sync' asking for files on server A and digest files on
server B where server B is any server in gentoo rsync rollover but not
server A...

Then, person have to compromise server A and server B to get his hack
working...

Hope this help

Cheers

--
Alex <alex [at] ssji>
Attachments: signature.asc (0.18 KB)


simons at cryp

Nov 7, 2004, 8:28 AM

Post #4 of 27 (2220 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

Marc Ballarin writes:

> Sorry if this sounds harsh, but calling this an exploit
> is ridiculous. [...] As it stands, it is plain FUD.

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
and Gentoo does, as of now, provide no way for me to
recognize this has happened.

You believe this is nothing more than FUD?


> If you download and execute untrusted code you are in
> danger.

This problem has nothing to do with trusted or untrusted
code, it is about data integrity. Or, more accurately, about
_lack_ thereof.


> (1) the server has not been compromised

How do I very this? Is there a list of SHA1 hashes of all
files /usr/portage is supposed to contain?


> (2) your connection has not been compromised

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.


> (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.


> However, none of those issues is specific to Gentoo or
> Open Source as a whole.

The fact that other projects have the same problem doesn't
mean that the problem shouldn't be fixed in Gentoo.


> You can verify the data, if:
> (1) a person has digitally signed the data

So why is the data apparently _not_ digitally signed then?


> (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.


>> (1) Do you agree that this is a problem?

> Of course. It is just in *no* way specific to Gentoo.

What does it matter whether the problem is specific to
Gentoo or not?


>> (3) Is there any estimate how long [fixing this problem]
>> will take?

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

So how long will it (approximately) take until this problem
is fixed?


> Remember: All that Gentoo can protect against are
> attempts to manipulate data on Gentoo's rsync or file
> mirrors from the outside. Nothing more.

Then why doesn't Gentoo _do_ that?


> So a signed Portage tree might improve security, but only
> against one of many risks.

One risk less to worry about.

Peter

--
gentoo-security [at] gentoo mailing list


Ballarin.Marc at gmx

Nov 7, 2004, 8:40 AM

Post #5 of 27 (2223 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

On 07 Nov 2004 14:14:28 +0100
Peter Simons <simons [at] cryp> 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 [at] gentoo mailing list


klieber at gentoo

Nov 7, 2004, 8:40 AM

Post #6 of 27 (2222 views)
Permalink
Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2) [In reply to]

On Sun, Nov 07, 2004 at 02:14:28PM +0100 or thereabouts, Peter Simons wrote:
> I would kindly request a statement from the Gentoo developers about this.

I'm a developer, but you should consider the following to be my opinion
only and not any sort of official statement.

> Specifically:
>
> (1) Do you agree that this is a problem?

As another poster already noted, of course it is, but it's not specific to
Gentoo. What happens if the server hosting the master repository of glibc
gets compromised? How do you know that hasn't already happened and there's
back doors galore on your machine right now? That may seem like a
smart-ass question, but stop for a moment and consider it seriously. How
do you *KNOW* that there are no backdoors in the version of glibc on your
computer right now?

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

We already implemented a major change nearly a year ago by moving
'rsync.gentoo.org' onto servers that are managed by the Gentoo team.
Previously, we relied on community mirrors which worked well, but didn't
allow us to ensure the servers were all held to the same high security
standard.

We've also taken a number of other steps to mitigate this type of exposure
including getting GPG signing into portage and the creation of an auditing
project which reviews the ebuilds and code used in our distribution.

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

n/a

> I have read some of the material Alexander hyper-linked to
> and, frankly, most of it is outright frightening.

Then you should immediately unplug your computer from the internet. The
minute you jack in, you're accepting some level of risk. That's just the
nature of the beast.

--kurt


rpfc at mega

Nov 7, 2004, 8:45 AM

Post #7 of 27 (2220 views)
Permalink
Re: Re: Is anybody else worried about this? [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1





Peter Simons wrote:
| This problem has nothing to do with trusted or untrusted
| code, it is about data integrity. Or, more accurately, about
| _lack_ thereof.

Security is always about trust. You have to trust someone or something.
Data, keys, servers, admins, protocols, passwords, algorithms, something...


| > (1) the server has not been compromised
|
| How do I very this? Is there a list of SHA1 hashes of all
| files /usr/portage is supposed to contain?

Where would you store that list? In a trusted server? Would you trust
the server admin of that server?


| > (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.

You need to trust the operator of the authentication server...


| > However, none of those issues is specific to Gentoo or
| > Open Source as a whole.
|
| The fact that other projects have the same problem doesn't
| mean that the problem shouldn't be fixed in Gentoo.

Agreed! This issue is important.


| > IMO the purely technical issues have been solved mostly.
| > However, those are smallest and least important part.
|
| So how long will it (approximately) take until this problem
| is fixed?

Well... I guess until someone comes up with a solution! Not the problem!
The problem is already known. Gentoo is based on the comunity. The
comunity has to come up with solutions. Not wait for highly payd
developers to solve everything like in some known corporations. At least
~ this is how I see Gentoo. Maybe I'm wrong...


Alex's ideia looks interesting:
| Just a question : could it be a good idea to move md5 on another server
| or to do 'emerge sync' asking for files on server A and digest files on
| server B where server B is any server in gentoo rsync rollover but not
| server A...
|
| Then, person have to compromise server A and server B to get his hack
| working...
|
| Hope this help
|
| Cheers

Redundancy could be a way to mitigate this problem. It wont solve it thou...



- ---
Rui Covelo




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBjkMQfLPhlaxNQk0RAvogAJ4o8042MBgvnqsp525orqXMfOn5/ACfR2Nb
5VmAOoUrvQAIRqmvg5khvB0=
=5aGG
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list


cdfrey at netdirect

Nov 7, 2004, 9:31 AM

Post #8 of 27 (2224 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

On Sun, Nov 07, 2004 at 03:40:34PM +0000, Marc Ballarin wrote:
> 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.

This is incorrect. On kernel.org, the signature files are in the same
directory as the kernel source tarballs, with ".sig" on the end.

RedHat's Fedora Core update mechanism checks the signature of each
downloaded package, and actually warns you if the check doesn't match
and asks whether you want to continue, which has happened on a number
of occasions for me.

Debian signs their main package tree as well, in the form of Packages and
Release files. While I'm not sure whether checking this is automatic in
apt, it is possible to do with a separate script, and I do use it. It
works quite well after a little setup.

- Chris


--
gentoo-security [at] gentoo mailing list


cdfrey at netdirect

Nov 7, 2004, 9:44 AM

Post #9 of 27 (2221 views)
Permalink
Re: Re: Is anybody else worried about this? [In reply to]

On Sun, Nov 07, 2004 at 03:45:21PM +0000, Rui Covelo wrote:
> | > (1) the server has not been compromised
> |
> | How do I very this? Is there a list of SHA1 hashes of all
> | files /usr/portage is supposed to contain?
>
> Where would you store that list? In a trusted server? Would you trust
> the server admin of that server?

The point is not to eliminate the need to trust some entity. The point
is to have to worry about the integrity of as few entities as possible.

A single vulnerability is better than multiple vulnerabilities.

> | > IMO the purely technical issues have been solved mostly.
> | > However, those are smallest and least important part.
> |
> | So how long will it (approximately) take until this problem
> | is fixed?
>
> Well... I guess until someone comes up with a solution! Not the problem!
> The problem is already known.

So is the solution. It was posted a few messages back. We just need some
admin to drop a find script on the main server and setup the required
keys. Once the signatures are there, anyone can write the userland script
to do the verification, but until then, there's no point to write it since
the server implementation is not known.

- Chris


--
gentoo-security [at] gentoo mailing list


cdfrey at netdirect

Nov 7, 2004, 10:01 AM

Post #10 of 27 (2225 views)
Permalink
Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2) [In reply to]

On Sun, Nov 07, 2004 at 03:40:46PM +0000, Kurt Lieber wrote:
> As another poster already noted, of course it is, but it's not specific to
> Gentoo. What happens if the server hosting the master repository of glibc
> gets compromised? How do you know that hasn't already happened and there's
> back doors galore on your machine right now? That may seem like a
> smart-ass question, but stop for a moment and consider it seriously. How
> do you *KNOW* that there are no backdoors in the version of glibc on your
> computer right now?

You don't. But that's like saying there's no point in closing the front
door since the bedroom window might be open. If the front door is closed
and locked, then at least we can pay more attention to the open window.

Plus, the glibc ebuild maintainer should be tracking the changes. He knows
what's going on in glibc land, he knows the build process, he should be
in touch with the main developers, and he should be reading the diffs.

If he doesn't have the time or skill to do that, he can at least compare
against the work of people who do, such as the source packages of Debian
or Fedora Core. It is pretty easy to do a diff.

Plus #2: both the glibc tarballs and the source packages of other distros
are signed. The glibc maintainer should have all those signatures on hand,
if needed, and be verifying them all before he puts the entire Gentoo
user base at risk.

I think this point is a red herring.

> > (2) Are there plans for getting it fixed?
>
> We already implemented a major change nearly a year ago by moving
> 'rsync.gentoo.org' onto servers that are managed by the Gentoo team.
> Previously, we relied on community mirrors which worked well, but didn't
> allow us to ensure the servers were all held to the same high security
> standard.

Excellent.

> We've also taken a number of other steps to mitigate this type of exposure
> including getting GPG signing into portage and the creation of an auditing
> project which reviews the ebuilds and code used in our distribution.

Fantastic.

> > I have read some of the material Alexander hyper-linked to
> > and, frankly, most of it is outright frightening.
>
> Then you should immediately unplug your computer from the internet. The
> minute you jack in, you're accepting some level of risk. That's just the
> nature of the beast.

That's rather condescending.

I would instead recommend that he compare Gentoo to other distros that take
package signing more seriously. It may be that the features and benefits
of a source-based distro like Gentoo outweigh the need for signed ebuilds,
like it does for me on one of my machines. But it also may mean that
some machines require the security and peace of mind of another distro's
signing practices and verification policies. Other machines I admin
fall into this category as well.

- Chris


--
gentoo-security [at] gentoo mailing list


rpfc at mega

Nov 7, 2004, 10:04 AM

Post #11 of 27 (2220 views)
Permalink
Re: Re: Re: Is anybody else worried about this? [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| So is the solution. It was posted a few messages back. We just need some
| admin to drop a find script on the main server and setup the required
| keys. Once the signatures are there, anyone can write the userland script
| to do the verification, but until then, there's no point to write it since
| the server implementation is not known.
|
| - Chris

Read Peter's message moments after sending mine.

I like Peter's idea. But the question is still, where to keep the public
key and private key. Yes, maybe it's better to trust the developers than
any mirror admin.

Adding to what Peter said, what about having the public and private key
changed periodicaly (developers come and go, keys should come and go
too) and have the portage download automaticaly the public key and
revokation certificates when needed from a single server? Ex: www.gentoo.org




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBjlWbfLPhlaxNQk0RAqfZAJsGaLid/8BzfXhQVbsNlLDKgfaUbQCggsW7
kc2rYAq3W0CdOCTgDYcQ0jQ=
=GziW
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list


krispykringle at gentoo

Nov 7, 2004, 10:07 AM

Post #12 of 27 (2226 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marc Ballarin wrote:
> 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.

Actually, kernel.org *does* sign their downloads; their public key is
available on any of the major TTP PGP servers (from which you download
using SSL signed by a trusted CA who's cert you already have installed
from when you got your computer or whatever). Microsoft at the very
least uses SSL of the same nature, but I suspect they also use digital
signatures on each package to provide the same security; I'm sure the
public key was pre-distributed with your computer.

RedHat provides the same faculty, based on GPG, with up2date. Many other
distros (Debian, for instance), do not, as far as I know, address this
problem in any way.

So it's not like we're really far behind the 8 ball here, but this *is*
a possible problem, the fix is well understood and implementable, and
some people do already fix it (and, in my opinion, it would be negligent
not to).

You *are* correct in highlighting the conditions that make this
exploitable, but they are not all that difficult to achieve (man in the
middle being pretty simple, if someone has access; compromised rsync
mirrors having happenned before).

I'm not tearing out my hair over this, and I'm still using Gentoo. But
it's worth noting that this is a risk that should be addressed.
- --
Dan "KrispyKringle" Margolis
Security Coordinator/Audit Project, Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQY5WZ7DO2aFJ9pv2AQKw2wgAnRt2Nr9835/eJmYVunFobnTzkOH8lYC1
F73s+i5iILZZd9Ljx0eo2B5+blATmcAcNQLkGmEfbjBK513OgZr0B+3bB2BvLVrN
m5S1h5VmHqST4n/IY0O1R4Kh8GZ8QHXyr91SEcsVtFLD+4Jiauqi9hamm8rI+P4M
Q72Ie1Kl6WIfDiqHAdfzYFenkFwNah/F3fkvWiosR2AHJbVSCXwcWiSAkZHXUaeu
XP05W7NEko/JjXmSeBdEEIaA2b3hjBC2PmVdTs8NmMDUgtbj2aQjE/FQfpIDotW7
puNPVlWVX5Oci6b21eiC65rmyiTdzI8BfoWot5tqSLsoUUHg8TbRBQ==
=xXwC
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list


cdfrey at netdirect

Nov 7, 2004, 10:11 AM

Post #13 of 27 (2228 views)
Permalink
Re: Re: Re: Is anybody else worried about this? [In reply to]

On Sun, Nov 07, 2004 at 05:04:29PM +0000, Rui Covelo wrote:
> Adding to what Peter said, what about having the public and private key
> changed periodicaly (developers come and go, keys should come and go
> too) and have the portage download automaticaly the public key and
> revokation certificates when needed from a single server? Ex: www.gentoo.org

Yes, I agree this is the way to do it. Debian, for example, has an annual
repository signing key.

- Chris


--
gentoo-security [at] gentoo mailing list


Barry.Schwartz at chemoelectric

Nov 7, 2004, 10:26 AM

Post #14 of 27 (2219 views)
Permalink
Re: Re: Is anybody else worried about this? [In reply to]

Marc Ballarin <Ballarin.Marc [at] gmx> wrote:
> 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.

Not so. Either you can't trust the developer, in which case his or
her signature _can_ be trusted (within reason) as an indication of
trouble; or it's just one of those things. Everyone makes a mistake
now and then, and no cryptography can stop that. And at least you
know (within reason) where the package came from, making analysis
after the fact simpler.


--
Barry.Schwartz [at] chemoelectric http://www.chemoelectric.org
If nothing is beneath them, and they control the machines of
election, and if we know these things, then what fools are we who
accept the election and plan for another like it?

--
gentoo-security [at] gentoo mailing list


simons at cryp

Nov 7, 2004, 10:56 AM

Post #15 of 27 (2224 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

Rui Covelo writes:

> what about having the public and private key changed
> periodicaly (developers come and go, keys should come and
> go too)

GPG keys can have a built-in expiry date. You create the key
with a life-time of, say 6 months. When that time is up, you
have to issue a new key. This approach limits the number of
revocation certificates you have to manage, and the
administrative overhead is neglectable. (Assuming you don't
create thousands and thousands of keys every week.)

The good thing about this is that it forces the users to
maintain their key-rings, because the keys will just stop
working when the deadline has passed. And, of course, it
doesn't stop you from issuing revocation certificates
nonetheless.


> and have the portage download automaticaly the public key
> and revokation certificates [...]

IMHO, the keys should be stored on the public key servers.
Gentoo may, of course, run its own mirror, but reusing
infrastructure that exists is a good thing.

I wouldn't want the software to fetch/update/revoke any keys
automatically, though. Assuming everything is properly
signed and authenticated, it shouldn't be a problem. But
automated key-ring management feels wrong to me.

Concerning the "TODO-list" I posted: There is another step I
forgot to mention. Verifying the hashes of the files that do
exist isn't quite enough, you also have to make sure that no
files exist which don't have a hash, so that attackers can't
add arbitrary files to the tree.

Peter


--
gentoo-security [at] gentoo mailing list


krispykringle at gentoo

Nov 7, 2004, 10:57 AM

Post #16 of 27 (2220 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marc Ballarin wrote:
> I think that improperly used signatures are a dangerous placebo.
> Developers have to be well aware of how to treat and use their keys.
> Users have to be thoroughly educated about the meaning of a signature (ie
> which guarantees it gives and which it cannot give).
> If this does not happen, there will be a lot of dangerous
> misunderstanding and - eventually - bad blood.

I find all this talk really strange. Basically, ``let's not implement a
security feature, because people might think it provides more security
than it does, and blame us when it does not provide that security.''

In fact, this *does* provide a clearly quantifiable security benefit, in
that rsync mirrors and channels of distribution (i.e. DNS servers,
routers, etc) need not be trusted. Currently, they must be trusted. So
this narrows the Trusted Computing Base down quite a bit, to get
technical, and anyone can see that this benefits security as a result.
Now, how much does it benefit? I don't know of a quanta to measure that in.

The point remains that this is a security benefit, and the only
arguments I've seen here against it are either that it's overhyped,
which is a meaningless argument and no reason not to implement it, or
that it's currently too difficult to do, which is not the case.

The reason it isn't implemented is becuase it takes a lot of people
getting on board before it works, right? Fine. I'm understanding, and
not terribly critical. But I think it's delusion to say that this
provides no security benefit; objectively, quantitatively, it does.
- --
Dan "KrispyKringle" Margolis
Security Coordinator/Audit Project, Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQY5iD7DO2aFJ9pv2AQKlcAf/cUmSkPNnAj3v8XQ3YxE0fJ1ynVOuyAt1
k+yPrcuPuz7jk4/+UDAt5MOvVZpaHY8jhNlV5ACPhyp8Dldo6mFIIGHkOYLvIuhr
O//tmN0RMkySXw4Lal/nQVD31vSMFUrcpXxnKOSsDXTJ+FeO5lU8hKQAowkuw4L2
t3evkWzvhbDEON9/X0D68tZG1m4dpBxQty+MibPwdtJyZ8tZkcLwr+LXXU2Q6uUn
LGPd1KG3wx1faVkNhDFBMbYYWrLemGKnSXVr0c7wkllMJNb83QzbbBA0yvE42jna
IDlF4ndH3MGB/N3myo8pfFZTt8WpK+xmOSqTVjTNmap7ImHkIsnI3w==
=35tM
-----END PGP SIGNATURE-----

--
gentoo-security [at] gentoo mailing list


Ballarin.Marc at gmx

Nov 7, 2004, 11:00 AM

Post #17 of 27 (2226 views)
Permalink
Re: Re: Is anybody else worried about this? [In reply to]

On 07 Nov 2004 16:28:04 +0100
Peter Simons <simons [at] cryp> 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 [at] gentoo mailing list


simons at cryp

Nov 7, 2004, 11:25 AM

Post #18 of 27 (2220 views)
Permalink
Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2) [In reply to]

Marc Ballarin writes:

> If a distributor promises package integrity through
> signatures, they are lying.

The signature doesn't promise that the package is "correct"
in any sense of the word, but it guarantees that it is the
same package Gentoo intended to distribute.

If you don't see how that improves security, then I frankly
don't know what else to say.


> This might work for glibc (Don't know, really.). But it
> certainly won't work for many other packages.

Again, this problem is not about glibc, it is about making
sure that data is distributed unmodified. I trust the Gentoo
developers to take care that the software they package up is
as secure as it can be. But I don't trust the Internet to
give me the same package that the Gentoo developers uploaded
to the main server.


> My point being: Manipulations can be subtle

Manipulations are impossible if the package is signed.


> If you use signatures to verify a package, you have to
> understand exactly what guarantees are given.

I do.


> The package or ebuild is identical to the version the
> Gentoo developer signed, provided that his workstation
> has not been compromised.

> Nothing else is guaranteed.

Then let's guarantee that and work from there, because
without that guarantee every other security measure is
pointless.

Peter


--
gentoo-security [at] gentoo mailing list


Ballarin.Marc at gmx

Nov 7, 2004, 11:34 AM

Post #19 of 27 (2228 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

On Sun, 07 Nov 2004 11:58:13 -0500
Dan Margolis <dmargoli [at] seas> wrote:

> Actually, kernel.org *does* sign their downloads; their public key is
> available on any of the major TTP PGP servers (from which you download
> using SSL signed by a trusted CA who's cert you already have installed
> from when you got your computer or whatever). Microsoft at the very
> least uses SSL of the same nature, but I suspect they also use digital
> signatures on each package to provide the same security; I'm sure the
> public key was pre-distributed with your computer.

They do, but a self-verifying executable, running with administrator
privileges is rather pointless. (Of course, the user could right-click and
check the properties, but who knows this?)
Additionally Microsoft (and probably Redhat) have the advantage of a
rather centralised structure. They have tight control over their network
and
their developers' workstations.
OTOH Gentoo's or Debian's developers are spread world-wide, which makes
key exchange and evaluation of the security of a developer's personal
computer quite difficult.

>
> RedHat provides the same faculty, based on GPG, with up2date.

The questions are: What are they signing? Have they audited the source
code from which they built the RPM? What are their guarantees?
(The last question was actually non-rethoric ;-)

As an example, a few years ago, Microsoft shipped a MSDN CD that contained
a virus. It wasn't signed, but had it been, the virus would have been
signed as well.

> So it's not like we're really far behind the 8 ball here, but this *is*
> a possible problem, the fix is well understood and implementable, and
> some people do already fix it (and, in my opinion, it would be negligent
> not to).

I think that improperly used signatures are a dangerous placebo.
Developers have to be well aware of how to treat and use their keys.
Users have to be thoroughly educated about the meaning of a signature (ie
which guarantees it gives and which it cannot give).
If this does not happen, there will be a lot of dangerous
misunderstanding and - eventually - bad blood.

If both - users and developers - are informed, then keys *are* a useful
measure that makes operation of mirrors easier and more realiable.
But it still does not improve the trust you should have into the software
as a whole.

Regards

--
gentoo-security [at] gentoo mailing list


dpn at isomerica

Nov 7, 2004, 11:35 AM

Post #20 of 27 (2224 views)
Permalink
Re: Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2) [In reply to]

On Sun, Nov 07, 2004 at 12:01:35PM -0500, Chris Frey wrote:
> On Sun, Nov 07, 2004 at 03:40:46PM +0000, Kurt Lieber wrote:
> > As another poster already noted, of course it is, but it's not specific to
> > Gentoo.

Does anyone know what 'BSD does or doesn't do to secure the /usr/ports
tree? Would these methods work for gentoo?

Dan

--
/--------------- - - - - - -
| Dan Noe, freelance hacker
| http://isomerica.net/


simons at cryp

Nov 7, 2004, 11:51 AM

Post #21 of 27 (2223 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

Marc Ballarin writes:

> I explicitly said that signing should be implemented!

Then what are we waiting for?

Peter


--
gentoo-security [at] gentoo mailing list


Ballarin.Marc at gmx

Nov 7, 2004, 12:04 PM

Post #22 of 27 (2225 views)
Permalink
Re: Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2) [In reply to]

On Sun, 7 Nov 2004 12:01:35 -0500
Chris Frey <cdfrey [at] netdirect> wrote:

> You don't. But that's like saying there's no point in closing the front
> door since the bedroom window might be open. If the front door is
> closed and locked, then at least we can pay more attention to the open
> window.

But you have not achieved more security. That is the point. If a
distributor promises package integrity through signatures, they are
lying. It is like showing of the locked front door without mentioning the
open bedroom window.

OTOH: If you are responsible for the front door's security, you should
close it, of course. This is why Gentoo *should* use signatures.
However, it is wrong to excpect or even promise a great improvement in
security through this measure.

>
> Plus, the glibc ebuild maintainer should be tracking the changes. He
> knows what's going on in glibc land, he knows the build process, he
> should be in touch with the main developers, and he should be reading
> the diffs.

This might work for glibc (Don't know, really.). But it certainly won't
work for many other packages. All the developer can do here is trust the
guy at the bedroom window - just to stay with that example.

>
> If he doesn't have the time or skill to do that, he can at least compare
> against the work of people who do, such as the source packages of Debian
> or Fedora Core. It is pretty easy to do a diff.

And Debian will compare against Gentoo, while Redhat compares gainst Suse,
who in turn...

My point being: Manipulations can be subtle, escpecially if they are
carefully planned. Many eys are necessary to spot them. Manipulations at a
low-level (a projects CVS-server) could easily propagate to many distros.
So it comes down to either check for yourself or trust the upstream
developers and their signatures and checksums.

If you use signatures to verify a package, you have to understand exactly
what guarantees are given.

This is exactly one thing:
The package or ebuild is identical to the version the Gentoo developer
signed, provided that his workstation has not been compromised.

Nothing else is guaranteed.

The reason signing still makes sense is numbers and probability. There are
only few developer machines, they are mostly unknown to attackers and are
hopefully not used as servers.

rsync mirrors, otoh, are many, well known and constantly exposed to the
internet.

Regards

--
gentoo-security [at] gentoo mailing list


Ballarin.Marc at gmx

Nov 7, 2004, 12:36 PM

Post #23 of 27 (2227 views)
Permalink
Re: Is anybody else worried about this? [In reply to]

On Sun, 07 Nov 2004 12:57:35 -0500
Dan Margolis <krispykringle [at] gentoo> wrote:

> I find all this talk really strange. Basically, ``let's not implement a
> security feature, because people might think it provides more security
> than it does, and blame us when it does not provide that security.''

I explicitly said that signing should be implemented! I only disagree with
the statement that it is a strong security measure or that it's lack is a
great danger to Gentoo users.

>
> In fact, this *does* provide a clearly quantifiable security benefit, in
> that rsync mirrors and channels of distribution (i.e. DNS servers,
> routers, etc) need not be trusted.

This and nothing more. Provided you find a secure way for key
distribution.

> Currently, they must be trusted. So
> this narrows the Trusted Computing Base down quite a bit

In the whole, this bit is quite small. The code that ends up on a Gentoo
system comes from millions of indivdual workstations and persons.
Well organized projects like KDE or the kernel have strict peer review and
provide signed packages themselves. Others lack both.

> technical, and anyone can see that this benefits security as a result.
> Now, how much does it benefit? I don't know of a quanta to measure that
> in.

Neither do I. At least, it closes a central and rather easy attack
channel, that could be used to hit a lot of Gentoo's users (easy once a
weakness in rsyncd is discovered).

But take a look here, to see how little this really means:
http://ftp.gnu.org/MISSING-FILES.README

This could have been used to hit almost every user of free software, and
no amount of signing by distributors would have changed anything.
As a consequence GNU started signing their checksums at the level of
package maintainers.
But this clearly shows, that signatures provide no real security unless
everyone in the "food-chain" does their part.
This is true between projects and inside projects.

Gentoo is almost at the top of the food chain, so their signatures are
only meaningful if the lower levels do their job properly and Gentoo
itself makes no mistakes.

Regards

--
gentoo-security [at] gentoo mailing list


klieber at gentoo

Nov 7, 2004, 4:26 PM

Post #24 of 27 (2227 views)
Permalink
Re: Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2) [In reply to]

On Sun, Nov 07, 2004 at 12:01:35PM -0500 or thereabouts, Chris Frey wrote:
> Plus, the glibc ebuild maintainer should be tracking the changes. He knows
> what's going on in glibc land, he knows the build process, he should be
> in touch with the main developers, and he should be reading the diffs.

If you believe this happens for even 20% of the packages in our tree,
you're mistaken. Most devs look at changelogs. Few devs look at code
diffs. Note I did not say "Gentoo devs".

> I would instead recommend that he compare Gentoo to other distros that take
> package signing more seriously. It may be that the features and benefits
> of a source-based distro like Gentoo outweigh the need for signed ebuilds,
> like it does for me on one of my machines. But it also may mean that
> some machines require the security and peace of mind of another distro's
> signing practices and verification policies. Other machines I admin
> fall into this category as well.

I would recommend that you, along with the other folks who have
misunderstood what this thread is about go back and re-read the original
post. This has nothing to do with signed ebuilds in portage. Signed
ebuilds in portage is something that is already implemented and supported
as an experimental feature as of 2.0.51:

http://www.gentoo.org/news/20041021-portage51.xml

The original poster was talking about the inability to verify *eclasses*,
not ebuilds. eclasses are an important part of portage from a features and
functionality perspective, but they make up a small fraction of the overall
tree in terms of sheer number of files. My point was and still is that
investing the time and effort to also sign these files isn't worth it given
the myriad of other larger holes that already exist further upstream.

We can argue all day long about whether or not to stick our finger in the
dike to plug the leak we see, but if there's a 3x3 hole just around the
bend that's gushing water, are we really serving any useful purpose?

Or, to leverage one of the primary tenets of FOSS -- if there are folks on
the list who truly believe this is a hole that should be fixed, provide
patches to portage to add this functionality. It already supports signing
to some degree -- one could reasonably assume that adding support for
signing of eclasses is relatively easy for a competent python programmer.

--kurt


cdfrey at netdirect

Nov 7, 2004, 6:03 PM

Post #25 of 27 (2220 views)
Permalink
Re: Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2) [In reply to]

On Sun, Nov 07, 2004 at 11:26:55PM +0000, Kurt Lieber wrote:
> If you believe this happens for even 20% of the packages in our tree,
> you're mistaken. Most devs look at changelogs. Few devs look at code
> diffs. Note I did not say "Gentoo devs".

I hope they at least check the signatures of the packages that have them
available.

This would be an interesting poll question, if we could get a number
of devs to participate (and not just Gentoo devs). :-)

I know I look at code diffs for packages that matter to me, and have done
code audits of certain software I rely on for security. I do realize that
there is the ever-present time constraints, but part of the advantage
of having multiple maintainers for a distro is that this kind of work
can be spread around.

> Signed ebuilds in portage is something that is already implemented
> and supported as an experimental feature as of 2.0.51:
>
> http://www.gentoo.org/news/20041021-portage51.xml

Given this release is only 2.5 weeks old, I hope you'll pardon my not
knowing this. :-) I'm quite pleased to see that this has reached the
experimental stage.

I just downloaded a fresh portage tree to take a look, and I notice
that signatures are making their way into the Manifest files. Is this
an automated process? If so, can we expect all the Manifest files to
soon be signed?

> The original poster was talking about the inability to verify *eclasses*,
> not ebuilds. eclasses are an important part of portage from a features and
> functionality perspective, but they make up a small fraction of the overall
> tree in terms of sheer number of files. My point was and still is that
> investing the time and effort to also sign these files isn't worth it given
> the myriad of other larger holes that already exist further upstream.

Wouldn't it be sufficient to put a Manifest file in the eclass/ directory
and sign it as well?

> Or, to leverage one of the primary tenets of FOSS -- if there are folks on
> the list who truly believe this is a hole that should be fixed, provide
> patches to portage to add this functionality. It already supports signing
> to some degree -- one could reasonably assume that adding support for
> signing of eclasses is relatively easy for a competent python programmer.

I note you mention this often, and I do appreciate the need for people
to join in and help out. The main roadblock to implementing new signing
procedures, for the outsider, is that it requires access to the server
to implement the signing, or it requires participation from all devs,
depending on the method chosen.

Given this roadblock, I don't think it is completely fair to lay this job
at users' feet.

What I'm trying to say is that signing doesn't have to be implemented for
the end user in portage before it is implemented on the server. Once the
signatures are available on the server, all this talk would go away, and
those that are concerned would do the checks, and those that aren't
wouldn't. The concerned would likely share their checking scripts as well.

So, I'm quite happy that there are experimental features in portage that
deal with this, but I'd be even happier if every Manifest file in the
portage tree was signed, even if portage code didn't do the checks yet.

- Chris


--
gentoo-security [at] gentoo mailing list

First page Previous page 1 2 Next page Last page  View All Gentoo security RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.