Mailing List Archive

No, apparently not. (was: Is anybody else worried about this?)
Kurt Lieber writes:

> 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. [...] The original poster
> was talking about the inability to verify *eclasses*, not
> ebuilds.

Okay. This is the point where I realize that I was wasting
my time.

There is a certain irony to the fact that you (and others)
go on and on lecturing me (and others), all the while it is
perfectly obvious that you have absolutely no idea what this
problem really *means*.

So if you guys would like to be the laughing stock of the
free software community once this vulnerability is exploited
for the first time, all I say is: Be my guest.

I am out of this thread.

Peter


--
gentoo-security@gentoo.org mailing list
Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
On Mon, Nov 08, 2004 at 12:52:42AM +0100 or thereabouts, Peter Simons wrote:
> There is a certain irony to the fact that you (and others)
> go on and on lecturing me (and others), all the while it is
> perfectly obvious that you have absolutely no idea what this
> problem really *means*.

Perhaps you haven't done a good job of educating us, then.

I will say that I was one of the folks arguing most strongly for getting
ebuild signing support in portage, so I certainly see the value in that
feature. I also see the value in getting signed eclasses in portage, but I
believe that value to be less and not as important as other things within
portage that I'd like to see.

> So if you guys would like to be the laughing stock of the
> free software community once this vulnerability is exploited
> for the first time, all I say is: Be my guest.

Gentoo is a community-based distribution. I'm sorry you see it as an "us
vs. them" thing. I'm also sorry you apparently ignored the part where I
said that if you believe this to be a serious problem, then please feel
free to provide patches that fix it. Being a community-based distro, we
rely on each other to make Gentoo a better distribution. We don't wait for
"them" to fix problems. Instead, we roll up our sleeves and become part of
the solution. Just because I don't personally agree with your
interpretation of this issue doesn't mean that you can't fix it.

--kurt
Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
Kurt Lieber writes:

> Perhaps you haven't done a good job of educating us, then.

Then I'll explain it one last time.

The entire contents of /usr/portage is not authenticated.
All the manifest files, all the patches, all the ebuilds are
obtained through a public network without _any_ form of
authentication.

This means that the wonderful SSP/PIE patches for gcc, the
SELinux kernel, the PaX additions, the digest-checking for
upstream packages -- it is all completely worthless, because
after you have performed an "emerge sync" you have no idea
what your system does.

Anybody who has access to a mildly central router or domain
name server in the Internet can take your machine over
completely without any effort at all. And as it happens,
there is (a) no way for the user to remedy this situation,
there is (b) no way to recognize this has happened, and (c)
the vulnerability has been known for over 1.5 years.

Does that make it any clearer why this problem might be
worth being solved, like, soon?

Peter


--
gentoo-security@gentoo.org mailing list
Re: Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
On Sunday 07 November 2004 5:05 pm, Peter Simons wrote:
> Anybody who has access to a mildly central router or domain
> name server in the Internet can take your machine over

Not to mention wireless data injection attacks, for anyone running a wireless
connection on their system.


--
Anthony Gorecki
Ectro-Linux Foundation
Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
Anthony Gorecki writes:

> Not to mention wireless data injection attacks, for
> anyone running a wireless connection on their system.

And let's not forget the added bonus that because Gentoo
builds everything from the source code, the attack is
completely platform independent and works nicely on x86,
AMD, PowerPC, and whatnot else.

Great job.

Peter


--
gentoo-security@gentoo.org mailing list
Re: Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
On Mon, Nov 08, 2004 at 02:05:26AM +0100 or thereabouts, Peter Simons wrote:
> The entire contents of /usr/portage is not authenticated.
> All the manifest files, all the patches, all the ebuilds are
> obtained through a public network without _any_ form of
> authentication.

That is factually incorrect.

Pick any Gentoo machine that has a reasonably recent portage tree and do
any of the following:

cat /usr/portage/sys-apps/portage/Manifest
cat /usr/portage/app-editors/vim/Manifest
cat /usr/portage/dev-lang/perl/Manifest

Those are but three examples. Certainly not all files are signed, but to
say that we're completely ignorant of the problem is a grossly unfair
mischaracterization.

> Does that make it any clearer why this problem might be
> worth being solved, like, soon?

It certainly does show that you haven't taken the time to understand what
features portage currently does and does not offer.

Again, nobody is arguing about signing ebuilds. That functionality already
exists as of .51 and we're working on getting devs to sign their ebuilds.
Work is *already* under way to solve this problem -- you're wasting your
breath if this is all you're concerned about.

The original message talked about eclasses and specifically, their lack of
versioning.

--kurt
Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
Kurt Lieber writes:

> Pick any Gentoo machine that has a reasonably recent
> portage tree and do any of the following:

> cat /usr/portage/sys-apps/portage/Manifest

You know, the good thing about this discussion is that I
really learned something: When I say "I am out of this
thread", then I should keep my word.

Peter


--
gentoo-security@gentoo.org mailing list
Re: No, apparently not. [ In reply to ]
Peter Simons wrote:
> So if you guys would like to be the laughing stock of the
> free software community once this vulnerability is exploited
> for the first time, all I say is: Be my guest.

How is this NOT a problem with every distribution that offers downloads
... oh, that's right ... ALL of them? Yep.

Instead of a bunch of hounds baying at the Gentoo devs, who do what they
do without much in the way of remuneration, and who have absolutely the
best intentions and concern for the user base ... why not HELP them
design a tool that can help ameliorate the risk to some acceptable level.

I'll agree that having signed files will be a step forward in security,
but also ack that in the larger scheme of things, it means little. But
progress in a forward direction is always a good thing. Now, how about
an independent signature/hash of the entire portage tree?

If I wanted something like that, I might start with some assumptions
(any of which may be false, but I'm using the assumptions to generate a
scenario):

1. The master machine (or cluster or whatever) is the source of
distribution to a limited set of secondary mirrors, from which all other
mirrors sync, and from those, end users sync.

2. So an end user is perhaps two, but likely three steps away from the
master.

3. The secondaries sync to the master on a known schedule ... let's say
hourly.

4. Commits to the master currently happen on no set schedule.

Okay, with those four assumptions, could we do something like this:

1. Queue up commits to the master for 55 minutes of every hour.

2. At minute 55, close off access by the secondary mirrors.

3. Apply the commits to the master.

4. Write a datestamp/serial number into the master, then run a hash
against it. Put that hash on the gentoo main site, and other places
where the portage tree is not mirrored, either appended to the hashfile
(as a serial number / hash pair) or as a standalone hash in a file
that's named for the serial number, in a directory full of such things.

For example:

export FILENAME=`date | md5sum | cut -f1 -d' '`
echo $FILENAME >> /usr/portage/serial_number
tar cf - /usr/portage --exclude distfiles | md5sum \
>> /root/$FILENAME

[.copy the /root/$FILENAME over to the appropriate distribution points,
webservers, whatever]

5. Reopen access by the secondaries.


Then, at the user end, after performing an emerge sync, the process is
run again, by portage:

export FILENAME=`cat /usr/portage/serial_number`
wget http://www.gentoo.org/$FILENAME
# thus retrieving the checksum for that particular
# snapshot
tar cf - /usr/portage --exclude distfiles | md5sum | \
diff - $FILENAME

If the checksums match, the diff returns 0, clean tree, and we can all
start worrying about the packages that are downloaded from the URLS
contained in each ebuild.

To break this, the main mirror can be compromised (one must presume that
this is protected) OR a secondary or tertiary mirror can be owned, along
with at least one source of the checksum file, which are independent of
all mirror machines. Of course, the combinations of mirror and checksum
sources mean that alarm bells will be going off pretty quickly, unless
the main mirror is owned. Then all bets are off, but eventually we all
die, right?

Okay, that's one scenario, based upon possibly silly assumptions. But it
or something like it could be implemented. I could probably even pretend
to be able to help with a portage patch, except that I have no concept
of the actual infrastructure for portage tree distribution, which will
tie into how portage works with such a scheme.

Let's be useful to the developers here, folks. Hell, I'm pissed off
about some of what I've read in this thread, and I don't have any axe to
grind in the matter.

HTH,

.brian

--
Brian Bilbrey : http://www.orbdesigns.com/
... maybe they can't be called "volunteers" any more if somebody
ends up being silly enough to pay them for something they'd have
done for free anyway. - Linus in the Seattle Times

--
gentoo-security@gentoo.org mailing list
Re: No, apparently not. [ In reply to ]
Brian Bilbrey writes:

> Then, at the user end, after performing an emerge sync,
> the process is run again, by portage:

> export FILENAME=`cat /usr/portage/serial_number`
> wget http://www.gentoo.org/$FILENAME

The process breaks at this point because if someone can
redirect your access to a sync mirror, he can redirect your
access to the web server, too. So the hash will always match
the portage tree because the attacker generated both.


> Let's be useful to the developers here, folks.

I have posted a concrete proposal that does fix the problem
long before this thread spun out of control.

Peter


--
gentoo-security@gentoo.org mailing list
Re: No, apparently not. [ In reply to ]
On Sun, 7 Nov 2004, Brian Bilbrey wrote:

> Peter Simons wrote:
> > So if you guys would like to be the laughing stock of the
> > free software community once this vulnerability is exploited
> > for the first time, all I say is: Be my guest.
>
> How is this NOT a problem with every distribution that offers downloads
> ... oh, that's right ... ALL of them? Yep.

Based on some comments I've read from others in this discussion, not
Debian. I suspect there may be others, but, quite frankly, I'm not
following many distributions right now.

> Instead of a bunch of hounds baying at the Gentoo devs, who do what they
> do without much in the way of remuneration, and who have absolutely the
> best intentions and concern for the user base ... why not HELP them
> design a tool that can help ameliorate the risk to some acceptable level.
>
> I'll agree that having signed files will be a step forward in security,
> but also ack that in the larger scheme of things, it means little. But
> progress in a forward direction is always a good thing. Now, how about
> an independent signature/hash of the entire portage tree?

RSYNC_EXCLUDEFROM.

A signature on the entire portage is only useful if people download the
entire portage. Further, since you're having this performed by the
server, if one compromised that server, they could compromise all Gentoo
systems. Finally, it means that one can only apply changes to the
master rsync server once an hour, and it takes up a fairly large amount
of resources when that happens.

Admittedly, that's assuming that the Gentoo baselayout maintainers have
resonably secure system - after all, no matter what, compromising a
baselayout maintainer's system, or to a lesser extent, any core herd
member's system, gives access to the whole pie. But there isn't
anything that can be done about that, other than making certain that
they're educated on security practices and follow them.


So how is it that having the Manifest files all signed, and having the
Manifest signatures checked, and checking all the MD5 sums in the
Manifest files against the files in the directories only a partial
answer? What openings remain for illicit content to make its way onto
the servers, without having gone through a dev?

Ed

--
gentoo-security@gentoo.org mailing list
Re: No, apparently not. [ In reply to ]
Ed Grimm writes:

> So how is it that having the Manifest files all signed,
> and having the Manifest signatures checked, and checking
> all the MD5 sums in the Manifest files against the files
> in the directories only a partial answer?

/usr/portage/eclass is not authenticated by this and
contains shell code that's (possibly) executed with
superuser privileges.

Peter


--
gentoo-security@gentoo.org mailing list
Re: Re: No, apparently not. [ In reply to ]
On Mon, 8 Nov 2004, Peter Simons wrote:
> Ed Grimm writes:
>
>> So how is it that having the Manifest files all signed,
>> and having the Manifest signatures checked, and checking
>> all the MD5 sums in the Manifest files against the files
>> in the directories only a partial answer?
>
> /usr/portage/eclass is not authenticated by this and
> contains shell code that's (possibly) executed with
> superuser privileges.

Would the obvious fix not be provide signed Manifest files for the
eclasses as well?

Ed

--
gentoo-security@gentoo.org mailing list
Re: No, apparently not. [ In reply to ]
Ed Grimm writes:

> Would the obvious fix not be provide signed Manifest
> files for the eclasses as well?

Yes, that would fix the problem. However, if you want to
make sure your tree is properly authenticated, you have
authenticate _every single file_ in it. In a day and age
where people can hack your machine by setting appropriate
pixels in a GIF image, I wouldn't take any unnecessary
risks. Having dozens of signatures split over dozens of
directories is not a (human-)failure-resistant procedure,
IMHO.

I am also not quite certain yet how to bootstrap the system
securely. For example: Where does the properly authenticated
GPG ebuild come from?

Anyway, if all files are covered by the manifests, then it
would be secure.

Peter


--
gentoo-security@gentoo.org mailing list
Re: Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
Hi!

On Mon, 08 Nov 2004, Kurt Lieber wrote:
> > The entire contents of /usr/portage is not authenticated.
> > All the manifest files, all the patches, all the ebuilds are
> > obtained through a public network without _any_ form of
> > authentication.
>
> That is factually incorrect.
>
> Pick any Gentoo machine that has a reasonably recent portage tree and do
> any of the following:
>
> cat /usr/portage/sys-apps/portage/Manifest

This does not contain a GPG signature here. Of all packages...

> cat /usr/portage/app-editors/vim/Manifest
> cat /usr/portage/dev-lang/perl/Manifest

I've run a script across the entire tree, collecting 43 different
signature keys IDs from Manifest files in all (from a total of
2074 signed Manifest files, making up about 1/4). Of those keys,
16 were unavailable on the Subkeys Public Key Network (listed
below). Where can I get those?

0x012E7061
0x1E37DA76
0x2D86E6F4
0x3526BFED
0x8256272E
0x8F01B50A
0x96E7B687
0xAD8D10B6
0xAF09E289
0xB0FAE1C1
0xBC58B271
0xC4BBD87A
0xCA9EC979
0xE95F7581
0xEB0E2EF7

Wondering,
Tobias
--
export DISPLAY=vt100

--
gentoo-security@gentoo.org mailing list
Re: Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
On Mon, Nov 08, 2004 at 10:19:27AM +0100 or thereabouts, Tobias Klausmann wrote:
> > cat /usr/portage/sys-apps/portage/Manifest
>
> This does not contain a GPG signature here. Of all packages...

It did when I typed that message last night. Someone must have committed a
new version of portage without signing things. I agree, portage should be
signed. It's still a new process for us, so it will take time to get to
100%.

> I've run a script across the entire tree, collecting 43 different
> signature keys IDs from Manifest files in all (from a total of
> 2074 signed Manifest files, making up about 1/4). Of those keys,
> 16 were unavailable on the Subkeys Public Key Network (listed
> below). Where can I get those?

Good question -- I don't know. They should be available on pgp.mit.edu,
but if they're not, then I'd suggest start filing bugs against those
individual packages. (NOT portage bugs)

--kurt
Re: Re: No, apparently not. [ In reply to ]
Tobias Klausmann wrote:

>>cat /usr/portage/sys-apps/portage/Manifest
>
> This does not contain a GPG signature here. Of all packages...

My /usr/portage/sys-apps/portage/Manifest does.

> I've run a script across the entire tree, collecting 43 different
> signature keys IDs from Manifest files in all (from a total of
> 2074 signed Manifest files, making up about 1/4). Of those keys,
> 16 were unavailable on the Subkeys Public Key Network (listed
> below). Where can I get those?
> [...]

I think you get the problem. There have been threads like this one in
the past (on gentoo-dev mostly), all discussing how easy signing is and
why isn't it already implemented. Signing is not hard. Trusting the
signature is. Having "eclasses signed" is necessary at some point. But
if you can't already trust the signatures that are today in portage,
it's not top priority.

We are aware of the problem. We're slowly getting Gentoo package
maintainers to sign their ebuilds. Next we'll have to establish the
chain of trust right, from a master key published on trusted media, to
published keys, to verification when using any file downloaded. Next
we'll plug the remaining holes. All of this takes time, in part because
portage modifications have to go slowly so that we don't just break
things for our existing users.

For the moment you still have to trust Gentoo rsync mirror
infrastructure security. In the future we will get that weak link
handled. And then we'll hurry to fix the new weakest link.

Note that getting the key from a public key server won't authenticate
anything. It will merely do the identification part. Anyone can submit a
key with a gentoo.org address to a public key server.

--
Thierry Carrez
Operational Manager, Gentoo Linux Security
Re: Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
Hi!

On Mon, 08 Nov 2004, Kurt Lieber wrote:
> > > cat /usr/portage/sys-apps/portage/Manifest
> >
> > This does not contain a GPG signature here. Of all packages...
>
> It did when I typed that message last night. Someone must have committed a
> new version of portage without signing things. I agree, portage should be
> signed. It's still a new process for us, so it will take time to get to
> 100%.
>
> > I've run a script across the entire tree, collecting 43 different
> > signature keys IDs from Manifest files in all (from a total of
> > 2074 signed Manifest files, making up about 1/4). Of those keys,
> > 16 were unavailable on the Subkeys Public Key Network (listed
> > below). Where can I get those?
>
> Good question -- I don't know. They should be available on pgp.mit.edu,
> but if they're not, then I'd suggest start filing bugs against those
> individual packages. (NOT portage bugs)

I just tried: none of them is. I'll file a slew of bugs today (or
maybe tonight, depending on when I can find the time).

What i think would be best is providing them by keyserver; I
suggest the subkeys.pgp.net network as pretty much all other
keyservers use server software which is buggy (details on that
can be found on the corresponding mailing lists for gnupg).

The idea of providing the keyring with the install images is a
double-edged sword: if I have no Internet, not having any keys
might be bad, but providing them with the image opens an attack
vector.

On the other hand, who will install untrustworthy stuff if he
can't access the Internet?

Greets,
Tobias

--
export DISPLAY=vt100

--
gentoo-security@gentoo.org mailing list
Re: No, apparently not. [ In reply to ]
Thierry Carrez writes:

> For the moment you still have to trust Gentoo rsync
> mirror infrastructure security.

No, you have to trust every single IP router on the path to
the mirror in addition to the domain name system.

Peter


--
gentoo-security@gentoo.org mailing list
Re: Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
On Mon, 8 Nov 2004 12:53:06 +0100
Tobias Klausmann <klausman@schwarzvogel.de> wrote:

> The idea of providing the keyring with the install images is a
> double-edged sword: if I have no Internet, not having any keys
> might be bad, but providing them with the image opens an attack
> vector.

This is a valid point, I was thinking along the lines of : when you get the install cd you have another cd that you can optionally stick in your machine, add the keys to your keyring, and start installing. You then know you have all the correct keys.

Ideally the devs would meet at some specified place (a gentoo keyparty) every six months or year or so to exchange keys and prove identites. Only these keys would be added to the cd. The logistics of this would be interesting, in the "old chinese proverb" meaning of the word. :)

Just a source of the keys when your installing would be nice, but I do see the the "double-edged" point.
Re: Re: No, apparently not. (was: Is anybody else worried about this?) [ In reply to ]
Peter Simons said:
> Anthony Gorecki writes:
>
> > Not to mention wireless data injection attacks, for
> > anyone running a wireless connection on their system.
>
> And let's not forget the added bonus that because Gentoo
> builds everything from the source code, the attack is
> completely platform independent and works nicely on x86,
> AMD, PowerPC, and whatnot else.
>
> Great job.
>

You, with caustic replies like that, you're not going to motivate anyone.



--
gentoo-security@gentoo.org mailing list