On Fri, 06 Mar 2015 10:20:27 -0500 "Rick \"Zero_Chaos\" Farina" <[email protected]> wrote:
> On 03/06/15 08:53, Mark Kubacki wrote: > > 2015-03-06 1:56 GMT+01:00 Rick "Zero_Chaos" Farina > > <[email protected]>: > >> > >> 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>
pgptE3LOBsDPs.pgp
Description: OpenPGP digital signature
