1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
---
title: Impact of SKS keyserver poisoning on Gentoo
---
The [SKS keyserver network has been a victim of certificate poisoning
attack](https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f)
lately. The OpenPGP verification used for repository syncing is protected
against the attack. However, our users can be affected when using GnuPG
directly. In this post, we would like to shortly summarize what the attack is,
what we did to protect Gentoo against it and what can you do to protect your
system.
<!--more-->
The certificate poisoning attack abuses three facts: that OpenPGP keys can
contain unlimited number of signatures, that anyone can append signatures
to any key and that there is no way to distinguish a legitimate signature
from garbage. The attackers are appending a large number of garbage signatures
to keys stored on SKS keyservers, causing them to become very large and cause
severe performance issues in GnuPG clients that fetch them.
The attackers have poisoned the keys of a few high ranking OpenPGP people
on the SKS keyservers, including one Gentoo developer. Furthermore, the
current expectation is that the problem won't be fixed any time soon, so it
seems plausible that more keys may be affected in the future. We recommend
users not to fetch or refresh keys from SKS keyserver network (this includes
aliases such as `keys.gnupg.net`) for the time being. GnuPG upstream is
already working on client-side countermeasures and they can be expected to
enter Gentoo as soon as they are released.
The Gentoo key infrastructure has not been affected by the attack. Shortly
after it was reported, we have disabled fetching developer key updates from SKS
and today we have disabled public key upload access to prevent the keys stored
on the server from being poisoned by a malicious third party.
The gemato tool used to verify the Gentoo ebuild repository uses
[WKD](https://wiki.gnupg.org/WKD) by default. During normal operation it should
not be affected by this vulnerability. Gemato has a keyserver fallback that
might be vulnerable if WKD fails, however gemato operates in an isolated
environment that will prevent a poisoned key from causing permanent damage to
your system. In the worst case; Gentoo repository syncs will be slow or hang.
The webrsync and delta-webrsync methods also support gemato, although it is
not used by default at the moment. In order to use it, you need to remove
`PORTAGE_GPG_DIR` from `/etc/portage/make.conf` (if it present) and put
the following values into `/etc/portage/repos.conf`:
[gentoo]
sync-type = webrsync
sync-webrsync-delta = true # false to use plain webrsync
sync-webrsync-verify-signature = true
Afterwards, calling `emerge --sync` or `emaint sync --repo gentoo` will use
gemato key management rather than the vulnerable legacy method. The default is
going to be changed in a future release of Portage.
When using GnuPG directly, Gentoo developer and service keys can
be securely fetched (and refreshed) via:
1. Web Key Directory, e.g. `gpg --locate-key developer@gentoo.org`
2. [Gentoo keyserver](https://keys.gentoo.org),
e.g. `gpg --keyserver hkps://keys.gentoo.org ...`
3. Key bundles, e.g.:
[active devs](https://qa-reports.gentoo.org/output/active-devs.gpg),
[service keys](https://qa-reports.gentoo.org/output/service-keys.gpg)
Please note that the aforementioned services provide only keys specific
to Gentoo. Keys belonging to other people will not be found on our keyserver.
If you are looking for them, you may try [keys.openpgp.org](
https://keys.openpgp.org/) keyserver that is not vulnerable to the attack,
at the cost of stripping all signatures and unverified UIDs.
|
GitWeb
