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