Mailing List Archive

Portage rsync security
Hi list!

Am I right that there is currently no way portage tries to verify that
the rsync-mirror is not spoofed?

Doesn't that pose a major threat? If I were able to manipulate the
domain name resolution, I could easily trick gentooers into making false
updates and thus executing a malicious program with root-permission on
their machine.


So, why isn't there some kind of public key authentication going on, at
least optionally?

By the way: How does gentoo's gpg-feature work. The man-page doesn't
contain an explanation.
Re: Portage rsync security [ In reply to ]
On Thu, Mar 20, 2008 at 6:45 AM, Florian Philipp
<lists@f_philipp.fastmail.net> wrote:
> Hi list!
>
> Am I right that there is currently no way portage tries to verify that
> the rsync-mirror is not spoofed?
>
> Doesn't that pose a major threat? If I were able to manipulate the
> domain name resolution, I could easily trick gentooers into making false
> updates and thus executing a malicious program with root-permission on
> their machine.
>
>
> So, why isn't there some kind of public key authentication going on, at
> least optionally?
>
> By the way: How does gentoo's gpg-feature work. The man-page doesn't
> contain an explanation.
>

An attacker would need to be able to manipulate both the rsync server
and the actual downloaded packages since Portage verifies checksums
(RMD160, SHA1, SHA256, size). This is possible, as you mentioned,
using DNS spoofing.

I guess one solution would be to resolve your rsync server's IP
address once (e.g. at boot) and include an IPtables rule for it
specifically. My BASH is not very good, but e.g.:

RSYNC='rsync'
FOO="`grep ^SYNC /etc/make.conf | sed 's/.*rsync:\/\/\([^ ]*\)/\1/'`"
BAR="${FOO%/*}"
IP="`nslookup $BAR | grep ^Address | sed 's/.*Address: \([^ ]*\)/\1/'
| head -2 | tail -1`"

for i in $IP
do
$IPT -A OUTPUT -o $EXTIF -p tcp -s $EXTIP -d $i --dport $RSYNC --syn
-m state --state NEW -j ACCEPT
$IPT -A INPUT -i $EXTIF -p tcp -s $i -d $EXTIP --sport $RSYNC --syn
-m state --state NEW -j ACCEPT
done

Assuming your /etc/resolv.conf was secure at boot, this (I think)
would protect your machine from DNS related attacks. Perhaps others
who are more knowledgeable can chip in here.

Sincerely,
Mansour Moufid
--
gentoo-security@lists.gentoo.org mailing list
Re: Portage rsync security [ In reply to ]
On Thu, Mar 20, 2008 at 07:49:12AM -0400, Mansour Moufid wrote:

[...]

> for i in $IP
> do
> $IPT -A OUTPUT -o $EXTIF -p tcp -s $EXTIP -d $i --dport $RSYNC --syn
> -m state --state NEW -j ACCEPT
> $IPT -A INPUT -i $EXTIF -p tcp -s $i -d $EXTIP --sport $RSYNC --syn
> -m state --state NEW -j ACCEPT

I think the last rule is useless. You should not get a respone from a
host which is "NEW", because it belongs to package, which was sent out
before.

> done

best regards

Koppensteiner Mario
Re: Portage rsync security [ In reply to ]
On Thursday 20 March 2008, Florian Philipp wrote:
> Hi list!
>
> Am I right that there is currently no way portage tries to verify
> that the rsync-mirror is not spoofed?
>
> Doesn't that pose a major threat? If I were able to manipulate the
> domain name resolution, I could easily trick gentooers into making
> false updates and thus executing a malicious program with
> root-permission on their machine.
>
>
> So, why isn't there some kind of public key authentication going on,
> at least optionally?
>
> By the way: How does gentoo's gpg-feature work. The man-page doesn't
> contain an explanation.

As Mansour already pointed out, the only check Portage currently does is
comparing checksums from the Manifest in your tree (rsync delivered)
against the files in the tree (also rsync, will be executed as root)
and those downloaded from SRC_URI (usually distfiles).

The only way to secure this is to employ signing at the very source
(CVS, core gentoo infra) and then check it on the user side. If you
want to do this right now, you can change your tree syncing to manually
download the gpg-signed portage-latest.tar.bz2 tree snapshots from your
local distfiles mirror and check them.

If you want to know more details on the plans we have to implement
signing via rsync, please read, and feel free to comment on:
http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/

Regards,
Robert
Re: Portage rsync security [ In reply to ]
Mansour Moufid wrote:
> An attacker would need to be able to manipulate both the rsync server
> and the actual downloaded packages since Portage verifies checksums
> (RMD160, SHA1, SHA256, size). This is possible, as you mentioned,
> using DNS spoofing.
>

I don't think this is exactly true, since when I do a emerge --rsync I
also get patches, which can get applied. It could also download a
different package without a second DNS spoof. Someone could change what
it is trying to download (SRC_URI), it fails to find it in the package
mirrors and downloads the package from a malicious site.


Russell Valentine
--
gentoo-security@lists.gentoo.org mailing list
Re: Portage rsync security [ In reply to ]
Robert Buchholz wrote on 03/20/2008 02:07 PM:

> (CVS, core gentoo infra) and then check it on the user side. If you
> want to do this right now, you can change your tree syncing to manually
> download the gpg-signed portage-latest.tar.bz2 tree snapshots from your
> local distfiles mirror and check them.

emerge-webrsync can do the downloading for you. The current version in
svn [1] should also be able to handle the verification, just note that
the key id changed to 239C75C4 [2].

Regards,
Matthias

[1]
<http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/emerge-webrsync?view=markup>
[2] <http://bugs.gentoo.org/show_bug.cgi?id=130039>

--
Matthias Geerdsen (vorlon)

Gentoo Linux Security Team
http://security.gentoo.org
Re: Portage rsync security [ In reply to ]
On Thu, 20 Mar 2008, Russell Valentine wrote:

> Mansour Moufid wrote:
>> An attacker would need to be able to manipulate both the rsync server
>> and the actual downloaded packages since Portage verifies checksums
>> (RMD160, SHA1, SHA256, size). This is possible, as you mentioned,
>> using DNS spoofing.
>
> I don't think this is exactly true, since when I do a emerge --rsync I also
> get patches, which can get applied. It could also download a different
> package without a second DNS spoof. Someone could change what it is trying
> to download (SRC_URI), it fails to find it in the package mirrors and
> downloads the package from a malicious site.
>

Hi all,

indeed the patches are MD5-checked against the Manifest files in the
portage tree itself, so i can't assure any integrity on the patches that
rely in the portage tree, in the case my rsync server is compromised or
spoofed.

There is no point in enforcing cryptography on the transport layer,
since this would prevent from making one's own local mirror like
described in :
http://www.gentoo.org/doc/en/rsync.xml#doc_chap2

Since the Gentoo main rsync mirrors list will change sometimes, it's
also difficult (but still feasible) to maintain a secured transport with
each of the main mirrors, with /etc/hosts, netfilter, or whatever that
is IP-based. And that does not protect from the remote server
compromise.

The integrity check is currently being implemented at the data level,
not the host level, through the way of GPG signatures of Manifest files:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6

As for today, 2483 Manifest files are signed, and 10065 are not.
Obviously, the most used packages are often those which are signed.
You also have to manually download the GPG public keys and trust them if
you want.

--
Raphael Marichez aka Falco
Gentoo Linux Security Team