Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Brian Dolbec]

On Fri, 06 Mar 2015 10:20:27 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@g.o> wrote:

> On 03/06/15 08:53, Mark Kubacki wrote:
> > 2015-03-06 1:56 GMT+01:00 Rick "Zero_Chaos" Farina
> > <zerochaos@g.o>:
> >>
> >> tl;dr webrsync-gpg is a built in feature of the package manager
> >> which OPTIONALLY adds a significant amount of security against the
> >> attacks described on your website.  This is not currently the
> >> default setting, however, it is described in many hardening guides
> >> for gentoo and widely used among the security conscious.
> >
> > Without numbers backing that up this is speculation.
>
> 5,7,16,38,42.  There are some numbers to back up what I'm saying.  I
> have been doing security work for over 15 years and I'm a professional
> pen-tester.  If you want to read the portage code to verify what I
> said that's fine, but I'm reasonably confident I distilled what
> portage does into english.
> >
> > Given the default settings (without webrsync-gpg)…:
> >
> >> (8) Wrong software installation.
> >
> > Observe the DNS requests for the rsync- or webrsync mirror. They're
> > not encrypted and give you a nice heads-up.
>
> Yup, dns is basically never encrypted, this is not new information or
> a new attack.
> >
> > A. (data in transit) It's almost never HTTPS and/or without
> > authentication, so you can easily proceed to hijacking the
> > connection.
> > - Primed that way (DNS) insert a new rule into a router (or
> > nameserver) along the path or within the DC to redirect the
> > transaction. (See "quantum insert".)
>
> Yup, this was discussed, however, it doesn't matter, and I'll explain
> why.  The portage tree itself is a tarball with a signature attached,
> that means that short of coercion, the information in the portage tree
> should be correct (in the case of webrsync-gpg).  The Manifest file
> for each package contains a sha256, sha512, and whirlpool hash for
> each file (including the source tarballs which would be downloaded to
> install) and ALL of them must match.  Good luck modifying the file
> and getting all three hashs to match, I would suggest that is
> statistically impossible. Yes, an attacker could easily pass any file
> they like, but portage would fail to validate it and refuse to
> continue.
> >
> > B. (data at rest) Bribe or coerce the owner of the (portage tree)
> > mirror. Manifests and ebuilds are not centrally signed and there is
> > no authoritative "signing transparency"/record (see "certificate
> > transparency").
> >
> Only the portage tree is centrally signed, and currently the manifest
> signatures aren't even verified automatically at this point.  Yes, I
> completely agree that a gentoo dev could be coerced or bribed to add
> malicious code to the repository which would then get signed and
> shipped with the secure tarball.  This avenue of attack is very
> difficult to stop.  If would be cool to have some kind of automated
> check for malicious codes, however, I doubt it would be all that
> effective.
>
> -Zero
>

I have refrained from replying till now because I don't consider myself
qualified to answer security issues like these.

But, for the few holes there are currently in portage's security
methods, there are already efforts underway to plug them.  Using a new
project called gentoo-keys (a gpg-key management app) portage will be
able to independently able to verify the gpg signed Manifest
files provided with each package.  So, even if the user does not use
the gpg signed emerge-webrsync method.  There will still be an
alternate authentication method on the package level.  There are other
steps being taken as well in other areas of the tree handling and
building as well, but portage verifying the Manifest file is the next
step being taken with gentoo-keys.  

What Zero did not mention was that a user can independently verify the
gpg signature of each Manifest file now.  The developer gpg keys are
listed and available.  The gentoo-keys project is just automating the
whole process.

-- 
Brian Dolbec <dolsen>