Mailing List Archive

Hello,

On 08 Nov 2004 14:47:15 +0100 you wrote:

> I will publish step-by-step instructions which explain in
> great detail how to ...
>
> (1) set up a fake sync mirror,
>
> (2) set up a transparent proxy for rsyncd connections that
> are routed through your machine,
>
> (3) configure your BIND daemon to pretend it had
> authoritative information for the gentoo.org zone that
> refers to your mirror rather than the real one, and
>
> (4) what to patch in /usr/portage/eclass/eutils.eclass to
> install appropriate exploit code on the user's machine
> once emerge is used for the next time.

Err... I think this description alone should do it, no need to waste
your time writing the n-th description of how to set up a transparent
proxy, setting up BIND and so on... You could write an ebuild
"hacked-up-rsync-mirror" which does this all, so that all of us
can do some testing :-)

But i doubt that you really manage to hack up my BIND, place a
transparent proxy in my connection to the net or convince me to use your
fake mirror. But go on, play... Don't complain here if you're the one
being laughed at on that mentioned mailing list...

HWH

--
gentoo-security@gentoo.org mailing list

Hans-Werner Hilse writes:

> But i doubt that you really manage to hack up my BIND,
> place a transparent proxy in my connection to the net or
> convince me to use your fake mirror.

Step #1: The problem doesn't exist.

Step #2: The problem may exist, but it isn't exploitable.

Step #3: The problem may be exploitable, but it is
extremely unlike to happen.

Step #5: Well, maybe it is a problem, but there are far
more serious problems, so we don't need to fix it.

Step #6: Even if it were worth fixing, it is way too
difficult to do.

Step #7: Alright, alright. We will fix it as soon as we
find the time.

Step #8: Great job, idiot, now that you have drawn attention
the fact that clueless user's machines can be
hacked, it is _your_ fault rather than the ours.

Step #9: Please download the latest Service Pack.


--
gentoo-security@gentoo.org mailing list

*discovers 'reply' doesn't send to the list - for about the sixth time in
as many months*
(Can someone please add a reply-to to the list software? It's a pain.)


Well, it's possible, but relatively moot. Unless you can automate it
or are the sys admin for some place (in which case you definately
shouldn't be doing this), It's a very specific attack with low yield.
Yes, it's not the strongest security, but if you need to hack an ISP
nameserver or proxy to exploit it it's pretty moot.

Admittedly, proxying modems and other such non-admin-installed
plug-and-forget hardware may be at risk. My dsl modem has the
stupidest setup - admin/admin as a default login, telnet access always
open to the 'net, and it can do dns proxying, although I don't think
it's in my ISP's default installation instructions. But with the bad
login, I'm sure some other people with the same modem didn't change
that and could be exploited. Yes, making portage authenticate somehow
would help...

Still, it sounds like a niche hack, I'll bet there are more pressing matters.

--Bart

--
gentoo-security@gentoo.org mailing list

On Monday 08 November 2004 07:47 am, Peter Simons wrote:
> Since most of you seem to be believe that the bug is really
> not that serious, I am certain this will worry you not in
> the least.

I assume that you intend to 'blow the whistle' because you are incapable or
unwilling to submit a patch for the issue yourself?

I agree that there is a lot of room for improvement in the portage security
system. Signed ebuilds are a good start, but without ways to verify those
signatures from a second source (presumably a different portage mirror),
signed ebuilds don't buy much security.

I wouldn't waste your time hypothesizing about a man in the middle attack.
While MOTM attacks are theoretically possible on many many protocols, they
are *not* a serious threat, because of the scale on which they must be
undertaken, and the general care taken to keep core routers secure. Small
scale MOTM attacks (like from a disgruntled employee) are certainly more
feasible, and more common, but still require a fair degree of sophisication.
Such an attacker for a small-scale MOTM attack probably has the
sophistication to undertake a different, easier exploit.

Others have already pointed out that Gentoo is a community based distribution.
We help each other. Picking fights with volunteers has probably taken about
as much time as it would have taken you to look at the python code and at
least propose a code *design* for a patch, even if you can't code it
yourself.

Regards,

- Brian

--
gentoo-security@gentoo.org mailing list

Bart <scarfboy@gmail.com> writes:

> *discovers 'reply' doesn't send to the list - for about the sixth time in
> as many months*
> (Can someone please add a reply-to to the list software? It's a pain.)

http://www.unicom.com/pw/reply-to-harmful.html


--
gentoo-security@gentoo.org mailing list

Brian G Peterson writes:

> I assume that you intend to 'blow the whistle' because
> you are incapable or unwilling to submit a patch for the
> issue yourself?

If you read the recent messages carefully, you'll find that
I have tried _numerous_ times to provide details how to
remedy the situation.


> I agree that there is a lot of room for improvement in
> the portage security system.

Then why don't we stop discussing what I know or don't know,
do or won't do, and talk about a solution? The vast majority
of text posted in this thread is concerned with all kinds of
things BUT finding a good, technical solution to a
vulnerability that _does_ exist.

Generating a signed hash list of all files is really not
that difficult. It would solve the problem in a matter of
hours for those who are concerned about it, and it would
probably set things in motion for a better solution to be
developed that solves the problem for all users as well as
possible.

So why is the Gentoo team so incredibly reluctant to do
anything about it?

Again:

(1) Configure your main site to update the portage tree
from CVS in a time interval that's sufficient large to
allow for the hash list to be generated. Someone else
already suggested once an hour. I can't say what is
appropriate since I don't know your setup.

(2) Calculate hashes for all files in the /usr/portage
hierarchy. One could probably use a trivial Makefile to
generate hashes incrementally, even, to ease the load
on the machine.

(3) Sign the hash file with a GPG key. That means that
either someone has to enter the pass phrase manually,
or you'll have to set up a pass phrase agent, or you'll
have to use a key without a password at all.

Everything but the first solution is sub-optimal but
still a _lot_ better than what we have now. If someone
manages to compromise the main site, we all have far
greater problems than a lost secret key, so even _if_
the pass phrase is empty we still gain security.

(4) Distribute the signed hash file with the portage tree.

(5) Provide scripts that verify the integrity of the tree
after an emerge sync _before_ any other code is run
that has been obtained from the network.

(6) Make the matching public key available on the key
servers, on the web site, and every other place that
you can think about. Give an expiry date of, say 3
months to make clear that this is an intermediate
solution that will change.

(7) Get as many people to sign the key as possible to
properly authenticate it.

(8) Write a security advisory that educates the users about
the problem.

Peter


--
gentoo-security@gentoo.org mailing list

On Mon, Nov 08, 2004 at 03:00:59PM +0100, Hans-Werner Hilse wrote:
> But i doubt that you really manage to hack up my BIND, place a
> transparent proxy in my connection to the net or convince me to use your
> fake mirror.

But maybe I could. I know, where you live. I know, where you work. I
know, how you access the wired. Scared? ;)

Unfortunately, I also know some guys in-the-middle personally, who
could do the same with me. Nevertheless, I trust them. But just in
case...

Peter Simons style sucks. But I am really interested in a solution and
I follow this discussion carefully.

Bis denne,
Aiko
--
Aiko Barz
aiko@chroot.de

the guy who wrote this just sounds bitter about that personal message he once
accidentally sent to a list. :-)

i agree with scarfboy, however. if for no other reason than that the author
receives duplicate copies when someone uses the "reply to group" feature.


--
-- ----------------------------------------------- --
~ ____ ___ ___ Derek C. Anderson ~
~ | _ | _ \| __| Computer Scientist / Tech Lead ~
~ | | || __/|| Computer Sciences Corporation ~
~ | |_|| \ ||_-- http://kered.org/professional ~
~ (_)___|_|_\|___/ public@kered.org ~
-- ----------------------------------------------- --



frank paulsen wrote:
> Bart <scarfboy@gmail.com> writes:
>
>
>>*discovers 'reply' doesn't send to the list - for about the sixth time in
>>as many months*
>>(Can someone please add a reply-to to the list software? It's a pain.)
>
>
> http://www.unicom.com/pw/reply-to-harmful.html
>
>
> --
> gentoo-security@gentoo.org mailing list
>

--
gentoo-security@gentoo.org mailing list

I've lost track on where we are on this thread.

That said -- there is a perfectly good standard for signing and
verifying files in large-scale collections of code. It's called a
signed JAR file. The 'jarsigner -verify my.jar' command works very
nicely.

http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html

The file format itself is ZIP rather than tar or gzip.

Peter -- I appreciate your efforts to raise the visibility of this
issue.

Andrew Jaquith
Senior Project Manager
Symantec Professional Services
196 Broadway
Cambridge, MA 02139
USA

Direct: 617.768.2711
Mobile: 617.501.3278
Fax: 617.621.1478
Email: ajaquith@atstake.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546
On Nov 8, 2004, at 10:02 AM, Peter Simons wrote:

> Brian G Peterson writes:
>
>> I assume that you intend to 'blow the whistle' because
>> you are incapable or unwilling to submit a patch for the
>> issue yourself?
>
> If you read the recent messages carefully, you'll find that
> I have tried _numerous_ times to provide details how to
> remedy the situation.
>
>
>> I agree that there is a lot of room for improvement in
>> the portage security system.
>
> Then why don't we stop discussing what I know or don't know,
> do or won't do, and talk about a solution? The vast majority
> of text posted in this thread is concerned with all kinds of
> things BUT finding a good, technical solution to a
> vulnerability that _does_ exist.
>
> Generating a signed hash list of all files is really not
> that difficult. It would solve the problem in a matter of
> hours for those who are concerned about it, and it would
> probably set things in motion for a better solution to be
> developed that solves the problem for all users as well as
> possible.
>
> So why is the Gentoo team so incredibly reluctant to do
> anything about it?
>
> Again:
>
> (1) Configure your main site to update the portage tree
> from CVS in a time interval that's sufficient large to
> allow for the hash list to be generated. Someone else
> already suggested once an hour. I can't say what is
> appropriate since I don't know your setup.
>
> (2) Calculate hashes for all files in the /usr/portage
> hierarchy. One could probably use a trivial Makefile to
> generate hashes incrementally, even, to ease the load
> on the machine.
>
> (3) Sign the hash file with a GPG key. That means that
> either someone has to enter the pass phrase manually,
> or you'll have to set up a pass phrase agent, or you'll
> have to use a key without a password at all.
>
> Everything but the first solution is sub-optimal but
> still a _lot_ better than what we have now. If someone
> manages to compromise the main site, we all have far
> greater problems than a lost secret key, so even _if_
> the pass phrase is empty we still gain security.
>
> (4) Distribute the signed hash file with the portage tree.
>
> (5) Provide scripts that verify the integrity of the tree
> after an emerge sync _before_ any other code is run
> that has been obtained from the network.
>
> (6) Make the matching public key available on the key
> servers, on the web site, and every other place that
> you can think about. Give an expiry date of, say 3
> months to make clear that this is an intermediate
> solution that will change.
>
> (7) Get as many people to sign the key as possible to
> properly authenticate it.
>
> (8) Write a security advisory that educates the users about
> the problem.
>
> Peter
>
>
> --
> gentoo-security@gentoo.org mailing list
>


--
gentoo-security@gentoo.org mailing list

ok lets move past the what if. or could be. I have read most of the
threads since the inception. Who is the moderator or top level person for
security for gentoo. Have they posted or addressed this on this thread or
in general? that part I was unable to find?

I dont mean to simplify or over complicate the matter. But is there a
legitamate solution or proposal on the table. I have read some great
ideas, and some very dis-heartening ones as well. Like most of you I
love gentoo, I love the concept behind it. So now lets move toward a
solution. There will be flaws with any of these ideas, but there has to
be a solution that will be a bit more secure and resolve some of the issue
at hand. wether that is PGP or .jar or DSA keys.


----- Original Message -----
From: "Andrew Jaquith" <ajaquith@atstake.com>
To: <gentoo-security@lists.gentoo.org>
Cc: "Peter Simons" <simons@cryp.to>
Sent: Monday, November 08, 2004 8:19 AM
Subject: *****SPAM***** Re: [gentoo-security] Re: Let's blow the whistle


> I've lost track on where we are on this thread.
>
> That said -- there is a perfectly good standard for signing and
> verifying files in large-scale collections of code. It's called a
> signed JAR file. The 'jarsigner -verify my.jar' command works very
> nicely.
>
> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html
>
> The file format itself is ZIP rather than tar or gzip.
>
> Peter -- I appreciate your efforts to raise the visibility of this
> issue.
>
> Andrew Jaquith
> Senior Project Manager
> Symantec Professional Services
> 196 Broadway
> Cambridge, MA 02139
> USA
>
> Direct: 617.768.2711
> Mobile: 617.501.3278
> Fax: 617.621.1478
> Email: ajaquith@atstake.com
> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546
> On Nov 8, 2004, at 10:02 AM, Peter Simons wrote:
>
> > Brian G Peterson writes:
> >
> >> I assume that you intend to 'blow the whistle' because
> >> you are incapable or unwilling to submit a patch for the
> >> issue yourself?
> >
> > If you read the recent messages carefully, you'll find that
> > I have tried _numerous_ times to provide details how to
> > remedy the situation.
> >
> >
> >> I agree that there is a lot of room for improvement in
> >> the portage security system.
> >
> > Then why don't we stop discussing what I know or don't know,
> > do or won't do, and talk about a solution? The vast majority
> > of text posted in this thread is concerned with all kinds of
> > things BUT finding a good, technical solution to a
> > vulnerability that _does_ exist.
> >
> > Generating a signed hash list of all files is really not
> > that difficult. It would solve the problem in a matter of
> > hours for those who are concerned about it, and it would
> > probably set things in motion for a better solution to be
> > developed that solves the problem for all users as well as
> > possible.
> >
> > So why is the Gentoo team so incredibly reluctant to do
> > anything about it?
> >
> > Again:
> >
> > (1) Configure your main site to update the portage tree
> > from CVS in a time interval that's sufficient large to
> > allow for the hash list to be generated. Someone else
> > already suggested once an hour. I can't say what is
> > appropriate since I don't know your setup.
> >
> > (2) Calculate hashes for all files in the /usr/portage
> > hierarchy. One could probably use a trivial Makefile to
> > generate hashes incrementally, even, to ease the load
> > on the machine.
> >
> > (3) Sign the hash file with a GPG key. That means that
> > either someone has to enter the pass phrase manually,
> > or you'll have to set up a pass phrase agent, or you'll
> > have to use a key without a password at all.
> >
> > Everything but the first solution is sub-optimal but
> > still a _lot_ better than what we have now. If someone
> > manages to compromise the main site, we all have far
> > greater problems than a lost secret key, so even _if_
> > the pass phrase is empty we still gain security.
> >
> > (4) Distribute the signed hash file with the portage tree.
> >
> > (5) Provide scripts that verify the integrity of the tree
> > after an emerge sync _before_ any other code is run
> > that has been obtained from the network.
> >
> > (6) Make the matching public key available on the key
> > servers, on the web site, and every other place that
> > you can think about. Give an expiry date of, say 3
> > months to make clear that this is an intermediate
> > solution that will change.
> >
> > (7) Get as many people to sign the key as possible to
> > properly authenticate it.
> >
> > (8) Write a security advisory that educates the users about
> > the problem.
> >
> > Peter
> >
> >
> > --
> > gentoo-security@gentoo.org mailing list
> >
>
>
> --
> gentoo-security@gentoo.org mailing list
>
>



--
gentoo-security@gentoo.org mailing list

Peter Simons wrote:

> So why is the Gentoo team so incredibly reluctant to do
> anything about it?

I don't like your style, but I think I can get your point. The current
system update setup is vulnerable to man in the middle attacks between
the master rsync server and the end user. And you think there is an easy
solution that can be set up really quickly that will mitigate that risk.
So you're not happy because you don't get why we don't already include
your solution.

First, please note that hose attacks are not that easy to perform and
that you probably have a lot to worry about if you have someone
malicious controlling all network flow and DNS information to your
machines. Saying this doesn't mean I am ignoring the risk you talk
about. I'm just putting it in perspective.

Second, "the Gentoo team" is not one person sitting in the dark and
saying "No, you're wrong, period.". It's a large group of volunteers,
and you'll find some of them (mostly security guys) have been battling
for years to get a good and secure update mechanism in Gentoo. For some
of them, security is highest prio, for others it's stability, for others
it's performance, etc. That's why things are going on slowly. And
frankly, we're way better now than we were a year ago.

Now on to your solution. As the funny guy with the beard says, security
is a trade-off, it's not a binary status. We are not "unsecure" now and
we'll not be "secure" with your solution applied. The risk here is that
someone controlling your network flow and/or poisoning Gentoo DNS
information can execute code with root privileges on any machine doing
sync and updates. Your solution mitigates that risk by securing the link
between the master rsync server and the end user using a signed digest
that is controlled at the end user level using a key downloaded by other
supposedly secure means, and kept updated by other supposedly secure
mechanism.

This does not mitigate the (supposed lower) risk of having the main
rsync mirror compromised, the Gentoo CVS tree poisoned by unauthorized
users, or getting a corrupted master public key from your
man-in-the-middle controlling-all-network-flow bad guy.

This is not the ultimate solution but one which has the merit of being
simple (from your point of view) to be set up and that secures a part of
the chain that you feel is the easiest to corrupt. So it's a band-aid,
waiting for something more serious (all tree file signing with
individual dev keys) to get ready. We'll let the concern of whether
applying such a solution will or will not slow down the set up of the
real one true good but too-slowly-coming security mechanism to others.

What are the trade-offs you forget because of your agenda ? I can think
of two, and being a security-oriented person, I suppose others with a
different agenda will find more.

First, this added security layer will mean that for all users (including
those who don't care) the speed of availability of software through
portage will be a bit lower. We'll have to sync rsync with CVS,
calculate the digest and sign it before having it replicated with the
second-order mirrors. How much time does it take to generate MD5 (+
probably SHA1 I suppose) of every file in portage ? I would like to
know. Some users might complain that the added security they don't care
about because they don't think MiM attacks likely on their systems will
slow software availability. Who cares it takes an extra 30 minutes ?
Tell that to those who sync 4 times per hour.

OK, next, the end user side. You'll have to hook up tree signature
verification to portage directly, as portage somehow executes code it
fetched from the network when updating metadata and performing profile
updates. We have a very large bunch of users (obviously not on this
mailing list) complaining that emerge sync is waaaay too slow. How much
time does it take to do MD5+SHA1 verification of every single file in
/usr/portage after the rsync is complete ? That also I would like to
know. That would help evaluate the real tradeoffs your solution implies.
An optional FEATURE ? Letting the no-clue users out of protection is not
nice, but I suppose it's needed by your solution.

Last, your simple solution means work for the infrastructure team (to
change the rsync replication process, provide for CPU time to perform
the digest etc... And the portage team (testing and releasing extra
functionality controlled by a FEATURE most people won't activate because
it slows down the emerge sync process). Rephrasing your proposal as :

(1) infrastructure scripts to generate signed digest
(2) portage patches including the FEATURE of glocal verification
(3) hard data showing the performance hit server-side and client-side

would certainly help us. It's not your job to do an implementation
proposal ? That's the "Gentoo team" job ? Man, get real. Gentoo is a
community distribution. The "Gentoo team" cannot do everything, it needs
user support. And yes, even posting a small script helps.

--
Thierry Carrez
Operational Manager, Gentoo Linux Security

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

Peter Simons wrote:
> Hans-Werner Hilse writes:
>
> > But i doubt that you really manage to hack up my BIND,
> > place a transparent proxy in my connection to the net or
> > convince me to use your fake mirror.
>
> Step #1: The problem doesn't exist.
>
> Step #2: The problem may exist, but it isn't exploitable.
>
> Step #3: The problem may be exploitable, but it is
> extremely unlike to happen.
>
> Step #5: Well, maybe it is a problem, but there are far
> more serious problems, so we don't need to fix it.
>
> Step #6: Even if it were worth fixing, it is way too
> difficult to do.
>
> Step #7: Alright, alright. We will fix it as soon as we
> find the time.
>
> Step #8: Great job, idiot, now that you have drawn attention
> the fact that clueless user's machines can be
> hacked, it is _your_ fault rather than the ours.
>
> Step #9: Please download the latest Service Pack.
>

First, as a caveat, this is me speaking as me, not as a Gentoo dev.

Peter, please try to remember what Kurt said before, that Gentoo is a
community-based distro and that there really is no ``them.'' Your
mentality seems to be that we're acting as a commercial entity might to
try to quash and cover up vulnerabilities that make us look bad. I've
only been at Gentoo a relatively short time, but in that time, I've had
access to both public and confidential vulnerabilities, and had a chance
to witness the Gentoo security process from the inside. That process is
designed solely to promote the absolute best security we can offer,
never to save face or gain marketshare.

Perhaps that sounds like a lot of marketing itself, but keep this in
mind: if more people use Gentoo, I don't get anything out of it (but
perhaps a little personal satisfaction). But if we do things
poorly--from a security standpoint--not only do we look stupid, but I
and the rest of the team are personally responsible for those who suffer
the repurcussions of our mistakes. So we have very little incentive to
cover-up a vulnerability, and every incentive to do what we can to
promote the best security available.

So why is this not being acted on? Well, this (in that it's a Portage
vulnerability) is somewhat outside the scope of my regular skills, I'll
admit. So I can't give you any definitive explanation. But--and I don't
mean this to urge you not to publish anything you'd like, as this is
already public knowledge--I think you'd do best to trust Kurt's reasons
on this. Being a community-supported distro, if every developer is busy
on something else of higher priority to him (and of course, we can
hardly just hire someone else to fix this), this might languish for a
while. And of course, if a user wants to see it fixed, that user can
always submit a patch.

But I'm not clear on what *your* goal is here by making a public stink.
It would seem you're trying to encourage the Gentoo Project to fix this,
which sounds pretty good and noble. Yet I have to wonder, for the amount
of time you're spending on this, couldn't you just write the patch
yourself at some point and save a lot of trouble?

I guess my final point here is to remember that we're just a bunch of
guys doing something we enjoy, and hopefully making a product that you
and some other people find useful. We aren't making a profit. We aren't
Microsoft. We aren't taking your money and then screwing you over behind
your backs (uh, metaphorically, of course). So if it seems we're
unresponsive, or unhelpful, or don't fix everything you'd like, just try
sometimes to be a little more understanding.

Thanks, Peter,
Dan

- --
Dan "KrispyKringle" Margolis
Security Coordinator/Audit Project, Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQY+bdLDO2aFJ9pv2AQJ3ZQgAyK1HltQcW8OcaE1nRHkKv9QnV4ioqVQV
yu2m7uEU2OGtAd25Xj5CUEpBOJiqsM4d1A8XprAunvA0CT6bvkkNzI/L47KkU/up
E2OIClj72uuBGA7RYqCMlozZcnNP0dijheqI8whU9/10dJxKZEQ3AhTRrxWB8QEN
mPqTQAJbM4iNU2R2c/pjPwWW62aNn3EENpLjBSMXJngV7DLzG5COXuxvUXryBFZ+
V9L15YpAlgr9qfrDizmMj/335dfot9gK9nsPK22ODfVUnCNzQQ6ZlFl+1BuqBhK3
B9XGjXtm/47qQQ3C4ke60+bcdoMdycape8LtqMsBP9jZI2GAbdKhmA==
=afXK
-----END PGP SIGNATURE-----

--
gentoo-security@gentoo.org mailing list

Dan Margolis writes:

> [the Gentoo security process is] designed solely to
> promote the absolute best security we can offer, never to
> save face or gain marketshare.

Good. I have a proposal how to the security of the
distribution could be enhanced by a bit. I have posted it 4
times by now. It would be way cool if the proposal would
find entry into the Gentoo security process so that a rather
fundamental problem in the distribution process can be
fixed. If there is a better way of doing things than what I
have suggested, then I am all ears. Doing nothing, however,
is not an answer I am prepared to accept and as of now I
have no indication that this problem is being solved or even
taken seriously.


> And of course, if a user wants to see it fixed, that user
> can always submit a patch.

I cannot submit any patch. There is no "patch". There is a
3-line shell script which someone who has administrator
privileges on the main server can put into the crontab, and
there is some GPG key which someone with administrator
privileges on the main server has to create. I can do
neither of that.


> But I'm not clear on what *your* goal is here by making a
> public stink.

My goal is to remedy a vulnerability in the Portage system
that has not been addressed for the last 1.5 years even
though it was known.


> I have to wonder, for the amount of time you're spending
> on this, couldn't you just write the patch yourself at
> some point and save a lot of trouble?

Add the key

ssh-dss AAAAB3NzaC1kc3MAAACBANHjGfHMVluJJEabXHuVvsmbbXu9hcC3G0KCU4RNGNR14tnv4FeDWIUZumrXfQ0V13D1zbOyw3IyEHTYVP7E1TNw+uEb7CjyGJY2TEyEROlDJ37mh5h8LVOrZbVZY/xHsNBgDiZccGKPkOwLcEzLiFJuDhMiQF67/Mzm69FVmCT9AAAAFQDpFMaASINIbv2ugG8R500QKz5ipwAAAIAZFWUJ5oU0p0zinH8Dk7V8SRXGtRr4LSWbncP1sza7AtQ+3RjtFfnPihAcjDJjzYw2rPeu+M140l3okB3A5P399XEW6pPuXW9wJVJLxJG4vZpsqHYrX6OX6kOjBBqU5RvPnWvXpKlUsYdJ3ZllDq5rmH0u26BBe7htsrhQzJPP/gAAAIEAmeN415RrRv95EVxFqpGIa7KqhIjktlLYVyy+8pFHoE1DV7MCaresaRAXTzHPpzHhU8mQ19MDObDZIhWnA9y5Qqk4UIUl7/8vF76FuCPEdsRZk5NX8GlIJAo0ghxKxdAJfHC+YGRSHL/l7eLS5WH//5vuw6egAl40UuwpEyF4O50= simons@peti.cryp.to

to ~root/.ssh/authorized_keys on the appropriate machine,
let me know how to log in, and I'll do it. I am serious.


> So if it seems we're unresponsive, or unhelpful, or don't
> fix everything you'd like, just try sometimes to be a
> little more understanding.

I would be a lot more understanding if this weren't about
the machines of completely clueless people who use the
system and have no idea at all what kind of risk they take
every time they update their portage tree. If nobody has the
time to fix this soon, then post a public security advisory,
and I'll back off immediately.


Thierry Carrez writes:

> [You] think there is an easy solution that can be set up
> really quickly that will mitigate that risk. So you're
> not happy because you don't get why we don't already
> include your solution.

Could we please STOP speculating about my feelings,
motivations, or deficits as an individual and address the
problem?


> [Please] note that hose attacks are not that easy to
> perform and that you probably have a lot to worry about
> if you have someone malicious controlling all network
> flow and DNS information to your machines. Saying this
> doesn't mean I am ignoring the risk you talk about. I'm
> just putting it in perspective.

I think it would be better to let the users -- who's
machines are at stake here -- decide whether they feel this
is a risk worth taking. Make the flaw public and explain
what it means, and we'll see what the community thinks about
the feasibility of man-in-the-middle attacks.


> Now on to your solution. As the funny guy with the beard
> says, security is a trade-off, it's not a binary status.
> We are not "unsecure" now and we'll not be "secure" with
> your solution applied. The risk here is that [...]

I understand the risk, I know what it means, I know how it
can be exploited, and I don't need it explained to me.
However, there are several thousand users out there on the
Internet who may not know about it.


> [Your solution] does not mitigate the (supposed lower)
> risk of having the main rsync mirror compromised, the
> Gentoo CVS tree poisoned by unauthorized users, or
> getting a corrupted master public key from your
> man-in-the-middle controlling-all-network-flow bad guy.

Duh, of course it does not. What is your point? It doesn't
solve every problem we have, so better not do it at all?


> First, this added security layer will mean that for all
> users (including those who don't care) the speed of
> availability of software through portage will be a bit
> lower.

Make a separate mirror then, which has signed and
authenticated contents that is updated only once a day, once
a week, whatever. Then those who care can use the secure
system with slower package availability and those who don't
care can stick with the insecure but fast version. Right now
there is no way to choose.


> How much time does it take to generate MD5 (+ probably
> SHA1 I suppose) of every file in portage ?

On my system it took a bit over 4 minutes. I have no idea
how fast your machines is. But we'll never find out unless
we try it.


> How much time does it take to do MD5+SHA1 verification of
> every single file in /usr/portage after the rsync is
> complete ?

I'd guess about as long as it takes to generate them. Those
you don't care can disable it.


> An optional FEATURE ? Letting the no-clue users out of
> protection is not nice, but I suppose it's needed by your
> solution.

The unfortunate truth is that you cannot protect users who
don't have a clue (because they don't verify the GPG key to
begin with), so I don't have a problem with making this
functionality optional.


> Last, your simple solution means work for the
> infrastructure team [...]

_Any_ solution will mean work for the someone. No solution
will mean a LOT more work once it turns out a couple of
systems have been compromised, because then you'll have
hundreds and hundreds of people like me flooding your
mailing lists with questions and complaints.


> It's not your job to do an implementation proposal ?
> That's the "Gentoo team" job ? Man, get real. Gentoo is a
> community distribution.

I keep hearing that over and over again, yet "Gentoo" seems
to be awfully unwilling to pay attention to the community
when it tries to help. Just so that we don't forget the
facts: One and a half years, guys. I have posted ... I dunno
... maybe 30 messages to this list by now? How much progress
have we made so far?

Let's get to work. Tell me what problem there is with my
proposal and I'll see whether I have ideas how to improve
it. Tell me a proposal of your own and I'll try to help
finding flaws in it. Give an account on the machine in
question and I'll to implement it.

Get this problem fixed or make it public and there is no
need for me to be "public stink".

Peter


--
gentoo-security@gentoo.org mailing list

On Mon, Nov 08, 2004 at 04:02:22PM +0100 or thereabouts, Peter Simons wrote:
> > I assume that you intend to 'blow the whistle' because
> > you are incapable or unwilling to submit a patch for the
> > issue yourself?
>
> If you read the recent messages carefully, you'll find that
> I have tried _numerous_ times to provide details how to
> remedy the situation.

You suggested one "solution" which is sub-optimal. When I privately
suggested an alternate solution that works better with the tools the devs
already use, scales far better and solves the problem more completely than
your solution does, you didn't want to hear about it. In fact, the very
next thing you did was post your "blow the whistle" nonsense.

You don't seem very interested in solving this problem. Instead, you seem
very interested in making a lot of noise.

> So why is the Gentoo team so incredibly reluctant to do
> anything about it?

Jason already said they were working on it and he explained why it wasn't
implemented yet. Please stop spreading FUD.

Why are *you* so reluctant to work on any solution other than the one you
came up with? Have you spent any time looking at the portage code? Do you
have any idea how long it would take to implement a solution using repoman?

You obviously feel quite passionately about this issue and just as
obviously don't like the timeframe being discussed for fixing this issue as
it stands. So why not take that passion and devote it to writing some
python code that fixes the issue? You claim you want to help Gentoo. Put
your code where your mouth is.

--kurt

On Mon, Nov 08, 2004 at 06:17:19PM +0100, Peter Simons wrote:
> Add the key
>
[...]
>
> to ~root/.ssh/authorized_keys on the appropriate machine,
> let me know how to log in, and I'll do it. I am serious.

*lol*

--
Aiko Barz
aiko@chroot.de

Kurt Lieber writes:

> When I privately suggested an alternate solution that
> works better with the tools the devs already use, scales
> far better and solves the problem more completely than
> your solution does, you didn't want to hear about it.

Look. I am really tempted to actually _post_ some of the
e-mail you sent me, because I feel that stuff like

| You aren't helping anyone. You're simply being an
| asshole. Welcome to my killfile, asshole.

suggests you are not perfectly objective about who stopped
talking to whom. Alas, it is a waste of time because you
won't be swayed from your opinion and the other readers on
the list don't care.

So to address your point

> You obviously feel quite passionately about this issue
> and just as obviously don't like the timeframe being
> discussed for fixing this issue as it stands.

instead, check out this:

| From: Kurt Lieber <klieber@gentoo.org>
| Cc: gentoo-security@lists.gentoo.org
| Message-ID: <20041107154046.GG10927@mail.lieber.org>
|
| [...]
|
| > (3) Is there any estimate how long this will take?
|
| n/a
|
| [...]


> So why not take that passion and devote it to writing
> some python code that fixes the issue? You claim you want
> to help Gentoo. Put your code where your mouth is.

Kurt, I am sorry, but I simply don't know how the internals
of your main site and mirroring system work. Without that
knowledge, there is really, really little I can do from
here. The problem is not implementing lots of Python code,
the problem is getting a bit of very simple shell code
_installed_ on the server in a way that makes sense.

So if your perception is that either I submit code RIGHT NOW
or I am not helping Gentoo, then I fear I am not helping
Gentoo.

Peter


--
gentoo-security@gentoo.org mailing list

Hi all,

I don't mean to join the ego fight, but I do think there are some good
points worth discussing here.

On Mon, 2004-11-08 at 17:14 +0100, Thierry Carrez wrote:
> Peter Simons wrote:
>
> > So why is the Gentoo team so incredibly reluctant to do
> > anything about it?
>
> I don't like your style, but I think I can get your point. The current
> system update setup is vulnerable to man in the middle attacks between
> the master rsync server and the end user. And you think there is an easy
> solution that can be set up really quickly that will mitigate that risk.
> So you're not happy because you don't get why we don't already include
> your solution.
My understanding is that Peter would prefer any solution to not having
one at all...

> First, please note that hose attacks are not that easy to perform and
> that you probably have a lot to worry about if you have someone
> malicious controlling all network flow and DNS information to your
> machines. Saying this doesn't mean I am ignoring the risk you talk
> about. I'm just putting it in perspective.
Sure, but I would argue that malicious upstrean servers are potentially
not that uncommon. Think of all the cyber-cafes, workplaces where too
many people have root access to critical machines, etc.
It would have to be a fairly well targeted approach, but the threat
exists nonetheless.

> Second, "the Gentoo team" is not one person sitting in the dark and
> saying "No, you're wrong, period.". It's a large group of volunteers,
> and you'll find some of them (mostly security guys) have been battling
> for years to get a good and secure update mechanism in Gentoo. For some
> of them, security is highest prio, for others it's stability, for others
> it's performance, etc. That's why things are going on slowly. And
> frankly, we're way better now than we were a year ago.
>
> Now on to your solution. As the funny guy with the beard says, security
> is a trade-off, it's not a binary status. We are not "unsecure" now and
> we'll not be "secure" with your solution applied. The risk here is that
> someone controlling your network flow and/or poisoning Gentoo DNS
> information can execute code with root privileges on any machine doing
> sync and updates. Your solution mitigates that risk by securing the link
> between the master rsync server and the end user using a signed digest
> that is controlled at the end user level using a key downloaded by other
> supposedly secure means, and kept updated by other supposedly secure
> mechanism.
Point taken, there is still a danger here, always will be somewhere.

> This does not mitigate the (supposed lower) risk of having the main
> rsync mirror compromised, the Gentoo CVS tree poisoned by unauthorized
> users, or getting a corrupted master public key from your
> man-in-the-middle controlling-all-network-flow bad guy.
Yes, but the important point is that you only need to get safe access to
the key *once* (possibly for all your systems). After that, no
man-in-the-middle can ever get in the way.

> This is not the ultimate solution but one which has the merit of being
> simple (from your point of view) to be set up and that secures a part of
> the chain that you feel is the easiest to corrupt. So it's a band-aid,
> waiting for something more serious (all tree file signing with
> individual dev keys) to get ready. We'll let the concern of whether
> applying such a solution will or will not slow down the set up of the
> real one true good but too-slowly-coming security mechanism to others.
Anything is better than nothing, I admit it would be a shame if it
slowed down other initiatives, but again, tough.

> What are the trade-offs you forget because of your agenda ? I can think
> of two, and being a security-oriented person, I suppose others with a
> different agenda will find more.
>
> First, this added security layer will mean that for all users (including
> those who don't care) the speed of availability of software through
> portage will be a bit lower. We'll have to sync rsync with CVS,
> calculate the digest and sign it before having it replicated with the
> second-order mirrors. How much time does it take to generate MD5 (+
> probably SHA1 I suppose) of every file in portage ? I would like to
> know. Some users might complain that the added security they don't care
> about because they don't think MiM attacks likely on their systems will
> slow software availability. Who cares it takes an extra 30 minutes ?
> Tell that to those who sync 4 times per hour.
Make it optional, as mentioned in another thread, it doesn't take very
long to generate sigs.

> OK, next, the end user side. You'll have to hook up tree signature
> verification to portage directly, as portage somehow executes code it
> fetched from the network when updating metadata and performing profile
> updates. We have a very large bunch of users (obviously not on this
> mailing list) complaining that emerge sync is waaaay too slow. How much
> time does it take to do MD5+SHA1 verification of every single file in
> /usr/portage after the rsync is complete ? That also I would like to
> know. That would help evaluate the real tradeoffs your solution implies.
> An optional FEATURE ? Letting the no-clue users out of protection is not
> nice, but I suppose it's needed by your solution.
Not needed, just an optional layer of protection.
IMHO, users who don't understand why they would need this feature have
more important things to worry about.

> Last, your simple solution means work for the infrastructure team (to
> change the rsync replication process, provide for CPU time to perform
> the digest etc... And the portage team (testing and releasing extra
> functionality controlled by a FEATURE most people won't activate because
> it slows down the emerge sync process). Rephrasing your proposal as :
>
> (1) infrastructure scripts to generate signed digest
> (2) portage patches including the FEATURE of glocal verification
> (3) hard data showing the performance hit server-side and client-side
>
> would certainly help us. It's not your job to do an implementation
> proposal ? That's the "Gentoo team" job ? Man, get real. Gentoo is a
> community distribution. The "Gentoo team" cannot do everything, it needs
> user support. And yes, even posting a small script helps.
I think anyone on this list is capable of writing the shell scripts
needed to generate the sigs, but fewer truly understand how that would
integrate with the gentoo servers, mirrors and portage. I certainly
don't!

my 2c, please don't flame - there is a high probability I am wrong.
Antoine


--
gentoo-security@gentoo.org mailing list

You can try hiting the reply to all button.


frank paulsen wrote:
> Bart <scarfboy@gmail.com> writes:
>
>
>>*discovers 'reply' doesn't send to the list - for about the sixth time in
>>as many months*
>>(Can someone please add a reply-to to the list software? It's a pain.)
>
>
> http://www.unicom.com/pw/reply-to-harmful.html
>
>
> --
> gentoo-security@gentoo.org mailing list
>

--
gentoo-security@gentoo.org mailing list

On 08 Nov 2004 18:17:19 +0100
Peter Simons <simons@cryp.to> wrote:

> Dan Margolis writes:
>
> > [the Gentoo security process is] designed solely to
> > promote the absolute best security we can offer, never to
> > save face or gain marketshare.
>
> Good. I have a proposal how to the security of the
> distribution could be enhanced by a bit. I have posted it 4
> times by now. It would be way cool if the proposal would
> find entry into the Gentoo security process so that a rather
> fundamental problem in the distribution process can be
> fixed. If there is a better way of doing things than what I
> have suggested, then I am all ears. Doing nothing, however,
> is not an answer I am prepared to accept and as of now I
> have no indication that this problem is being solved or even
> taken seriously.

The problem is that your proposal doesn't work for Gentoo as it's way
to centralized. You want to make a huge list with checksums for all
files and then sign that file. The major problem is that a) this list
would have to be regenerated at every commit or at least each rsync
update, b) signing would have to be automated which is pretty much a
no-go and c) it would have to be done on the cvs server or the master
rsync mirror, both are AFAIK already pretty loaded boxes. FYI: the rsync
update interval is 30 minutes and other actions have to be performed in
that window that probably interfere with the checksum generation.

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

Marius Mauch writes:

>> (1) Run "find /usr/portage -type f | xargs sha1sum -b"
>> on the Gentoo main system.

> What's the 'Gentoo main system'?

The one that carries the authoritative portage tree which
the secondary systems mirror.


>> (2) Sign the output with GPG.

> Who does that?

A script? I already commented on the problem of entering the
pass phrase, so I won't repeat it.


> Basically we do that already with Manifests, just that
> they don't cover the whole tree (yet).

Right. And the fact that they don't cover the whole tree is
exactly the problem I am talking about.


> signing of eclasses/profiles isn't done because of policy
> details

How long do you estimate will it take to get these problems
sorted out?


> But signature verification is a completely different
> beast.

The signatures have to be verified manually anyway, at least
initially. So I am fine with Portage not doing it for me as
long as the signatures _exist_.


> You want to make a huge list with checksums for all files
> and then sign that file. The major problem is that a)
> this list would have to be regenerated at every commit or
> at least each rsync update,

You can use the CVSROOT/* hooks to regenerate only the
hashes for those files that have actually changed. And that
"huge" file is more like 7 MB.


> b) signing would have to be automated which is pretty
> much a no-go

It is a lot better than not signing at all, IMHO. I also
commented on this before, so I won't repeat it.


> c) it would have to be done on the cvs server or the
> master rsync mirror, both are AFAIK already pretty loaded
> boxes.

Hashes can be regenerated incrementally; creating the
signature takes less than a second. Any decent system should
be able to survive that, IMHO. Should this turn out to be
absolutely *impossible*, then I guess you'll need a hardware
upgrade no matter what kind of authentication scheme you
would like to implement.


> the rsync update interval is 30 minutes and other actions
> have to be performed in that window that probably
> interfere with the checksum generation.

On my machine, which is not very fast at all, the entire
hash file can be regenerated from the scratch in about 4
minutes. So even if it takes 10 minutes on the Gentoo
system, that still leaves plenty of time for the other
tasks. It does require some attention to detail that these
processes don't interfere with each other, though. I guess
one would have to _try_ it.

Peter


--
gentoo-security@gentoo.org mailing list

On Mon, Nov 08, 2004 at 06:01:18PM +0000, Kurt Lieber wrote:
> You suggested one "solution" which is sub-optimal.
[snip]
> You don't seem very interested in solving this problem. Instead, you seem
> very interested in making a lot of noise.

Peter's latest suggestion on the list was quite detailed and would
seem to work now. He even suggested that the global signing key
be auto-revoked in 3 months, to let it be known that it is a temporary
measure.

I think that those concerned enough to run the verification script would
not mind the occasional missing sha1sum from a file that wasn't checked
in the proper time window. They would just delete that particular file,
or sync again.

I think this is ideal. It provides a (sub-optimal) solution
that works over night, while not hindering any forward progress on the
optimal one.

If someone posted a working and self-tested shell script that does this
task, could it be installed? Who do we contact to make that decision?

In hope,
- Chris


--
gentoo-security@gentoo.org mailing list

On Mon, 08 Nov 2004 15:59:23 +0100, frank paulsen <frank.paulsen@gmx.net> wrote:
> Bart <scarfboy@gmail.com> writes:
>
> > *discovers 'reply' doesn't send to the list - for about the sixth time in
> > as many months*
> > (Can someone please add a reply-to to the list software? It's a pain.)
>
> http://www.unicom.com/pw/reply-to-harmful.html

Okay, I'll use the reply-to-all on gmail. See how it's annoying? I am
*not* going to continually do the work of a
click-click-select-delete-click every single message because it's
against someone's sense of purism.

Fact: When I reply to a list message, it's meant to go to the list 99%
of the time.
Educated guess: That's true for most people, any mail client abilities
vary. Notably, a minority of us uses elm:)

The argument that we've taken a feature away is not too valid in this
case - if you want to send to the author, you can. It'd be called
'reply to all', or 'thinking about what address to use'.
In the meantime, my replying to the list isn't replying to the list,
and as far as I can remember, this is the only list that does it this
way, which makes it counterintuitive, and I don't necessarily ever
even notice my mistake.

I don't think it disturbs threading, and there's little point in
accurate tracking of who said who when you have all the mail anyhow.
You'll find it easily even if you don't do gmail-laziness.

It's evil, but as far as I can see, a lesser one, or at least a less
annoying one.

But yeah, whatever, I'll survive. Just don't count on me always replying:)

--
gentoo-security@gentoo.org mailing list

On Monday 08 November 2004 2:22 pm, Bart wrote:
> Okay, I'll use the reply-to-all on gmail. See how it's annoying? I am
> *not* going to continually do the work of a
> click-click-select-delete-click every single message because it's
> against someone's sense of purism.

Really, it's very simple: In my case, to reply solely to the author, I press
"R". To reply to the mailing list, I press "L". To reply to everyone
applicable, I press "A". Please don't complain about the fact that your web
based email client isn't functioning like a real email client: it isn't a
real email client.

Ideally, GMail would read the message headers and would support a
reply-to-list feature, however if it does not, we're not the ones to which
you need to direct your frustrations.


--
Anthony Gorecki
Ectro-Linux Foundation

lOn Mon, 8 Nov 2004 14:31:44 -0800, Anthony Gorecki
<anthony@ectrolinux.com> wrote:
> On Monday 08 November 2004 2:22 pm, Bart wrote:
> > Okay, I'll use the reply-to-all on gmail. See how it's annoying? I am
> > *not* going to continually do the work of a
> > click-click-select-delete-click every single message because it's
> > against someone's sense of purism.
>
> Really, it's very simple: In my case, to reply solely to the author, I press
> "R". To reply to the mailing list, I press "L". To reply to everyone
> applicable, I press "A". Please don't complain about the fact that your web
> based email client isn't functioning like a real email client: it isn't a
> real email client.

There's a simple general test for what we call reality - that which
doesn't go away when you stop thinking about it.

The argument that your specific client (probably a minority client -
regardless of how cool it is and how much I would probably think
so too if I used it) does have this specific feature work doesn't
really help most people, who probably use their client for another
feature yours probably doesn't have. Their choice, and no program
is perfect.

Does Outlook have this? Eudora? Thunderbird? Yahoo webmail? Hotmail?
Gmail? Kmail? Pine? Mutt? Two or three, perhaps.
The rest, which probably summarizes about everyone else, have to learn
to go "Oh right, the *gentoo* lists - did I just reply to the author?
Shit. Lemme
check my sent thing. Right. Copy... Oh, copy address first. Uh. Copy, paste,
copy, paste, send with apology to double dude".

In the end, computers are a tool to make things you want to do work as
simply as they can. You'll notice most people don't do what's technically
possible, but what's *simple*. Laziness, Impatience, Hubris, anyone?:)

I agree that this should be a supported client feature - but it isn't.
Whatever the reason is, it's not going to be resolved, for now it
clashes with people's intuition, and in many cases will probably make
people work at something that could be automatic.


> Ideally, GMail would read the message headers and would support a
> reply-to-list feature, however if it does not, we're not the ones to which
> you need to direct your frustrations.

Ideally, yes. I'ld like that. Practically? I doubt it'll happen, even with
gmail's general clean-yet-featured attitude.

Not frustrated, just explaining my point of view. Now, all the people who
will be getting double emails from now on may be. (Laziness, Impat..
Er, yeah. Simplest solution.)

--Bart

--
gentoo-security@gentoo.org mailing list