There have recently been some issues with the PGP SKS keyservers, this provides background: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f tl;dr is that you can "poison" a key on the keyserver by attaching a large number of signatures to it. This can both slowdown the keyserver and make the key in gnupg unusable. I believe this can be used as a DoS attack against portage users during sync. When a user runs "emerge --sync" in a default setting the following happens: 1. portage tries to update the gentoo release key via WKD (i.e. fetching it from gentoo.org via https). 2. If that fails it falls back to try to fetch the key via HKPS from hpks.pool.sks-keyservers.net. I believe this means the following attack is possible for a network attacker: 1. Attacker "poisons" the gentoo release key with bogus signatures on the sks keyservers. The keyserver gossip protocol will distribute it to all keyservers. 2. Attacker blocks connections to gentoo.org, e.g. by sending false DNS answers or simply blocking connections to the server's IP. The user would end up with an oversized portage release key that gnupg cannot handle properly, thus making further syncing impossible. I obviously haven't tried this on the real keyservers due to the fallout this might have, but we should be prepared for the fact that this can happen. I also haven't tried to replicate this in a local setup due to the complexity involved, so some of my assumptions may be false, but I believe the attack is straightforward enough to be plausible. My first thought would be that we might want to simply restrict portage to fetch keys via WKD. This means fetching from gentoo.org, which is infrastructure under our control. (Though I hope there's no script running that automatically synchronizes the key placed on gentoo.org with the keyservers.) Alternatively there's now keys.openpgp.org, which is a new keyserver that doesn't publish arbitrary signatures to keys and only publishes identifying email information that has been verified. But I'm not sure a fallback to a keyserver is necessary at all.
The probability of it happening is very low as you'd have to fail the WKD step to begin with before any vector appears. Currently only 3 keys are known to be affected (mine being one of them, apparently). For our purposes it should also be able to mitigate this with import-minimal or import-clean --import-options. I haven't actually encountered any issues anywhere with a keyring that contains the affected keys either, so the impact of this can be disussed. Of note is also that gemato uses emphemeral keystore, so getting poision once doesn't have permanent effect on system. E.g presuming WKD does fail and it gets an unusable TPK from keyserver; on the next run when WKD is back up it will be used and things will work again. Any reason this is security restricted? the issue is already publicly well discussed. Adding a group / project to CC list doesn't work for restricted bug in any case as it needs to be expanded for people to actually view the bug. Instead of expanding I'm making the bug public in this case.
> Of note is also that gemato uses emphemeral keystore, so getting poision once doesn't have permanent effect on system. Thanks for pointing this out, this indeed changes the whole threat scenario to be much less of an issue. I thought this could *permanently* make portage sync unusable, thus I thought this is a big deal, but it seems this is not the case.
(In reply to Hanno Boeck from comment #2) > > Of note is also that gemato uses emphemeral keystore, so getting poision once doesn't have permanent effect on system. > > Thanks for pointing this out, this indeed changes the whole threat scenario > to be much less of an issue. I thought this could *permanently* make portage > sync unusable, thus I thought this is a big deal, but it seems this is not > the case. There are simpler ways to completely block syncing, and also less visible.
Hmm, I just realized that what we said so far affects gemato, i.e. rsync & git verification. Webrsync still uses hand-written gpg calls, and they are potentially vulnerable to all that stuff.
(In reply to Michał Górny from comment #4) > Hmm, I just realized that what we said so far affects gemato, i.e. rsync & > git verification. Webrsync still uses hand-written gpg calls, and they are > potentially vulnerable to all that stuff. These days we have webrsync support for key refresh via gemato, using a /etc/portage/repos.conf settings like this: > [gentoo] > sync-type = webrsync > sync-webrsync-verify-signature = true The code is in this commit from bug 661838: https://gitweb.gentoo.org/proj/portage.git/commit/?id=726789b64dd713a761ebdc78abb3d64fff2a7984
Also, emerge-delta-webrsync support gemato using a configuration like this: > [gentoo] > sync-type = webrsync > sync-webrsync-delta = true > sync-webrsync-verify-signature = true The code is in this commit from bug 661838 and it's supported with the current stable app-portage/emerge-delta-webrsync-3.7.5: https://gitweb.gentoo.org/proj/portage.git/commit/?id=f810f8694f78dd87172e38d942580532017db4fe
Is it enabled by default? Does Portage switch to it automatically for people who previously had old verification codepath enabled?
(In reply to Michał Górny from comment #7) > Is it enabled by default? Does Portage switch to it automatically for > people who previously had old verification codepath enabled? No, it requires explicit configuration by setting sync-webrsync-verify-signature = true in repos.conf. I suppose we should probably enable it by default and drop support for the old verification codepath.
For current versions of portage, we should advise users to remove any PORTAGE_GPG_DIR setting that they may have in /etc/portage/make.conf. When PORTAGE_GPG_DIR is unset and they have the sync-webrsync-verify-signature = true setting in repos.conf, if they try to directly invoke emerge-webrsync/emerge-delta-webrsync then it will automatically abort with a message like this: > Do not call emerge-webrsync directly, instead call emerge --sync or emaint sync. When they call emerge --sync or emaint --sync, emerge/emaint will automatically export a PORTAGE_GPG_DIR setting that refers to gemato's temporary gpg during the emerge-webrsync/emerge-delta-webrsync call.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=909c967e7480e2477e40172bab5817b31ea200f0 commit 909c967e7480e2477e40172bab5817b31ea200f0 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-07-11 03:45:08 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-07-11 04:03:07 +0000 sys-apps/portage: Bump to version 2.3.69 #642604 handle empty EPREFIX, ROOT, SYSROOT, etc settings #689072 default repo.conf sync-openpgp-keyserver to hkps://keys.gentoo.org in order to prevent key poisoning #689506 default repos.conf sync-webrsync-verify-signature for USE=rsync-verify Bug: https://bugs.gentoo.org/642604 Bug: https://bugs.gentoo.org/683434 Bug: https://bugs.gentoo.org/689072 Bug: https://bugs.gentoo.org/689506 Package-Manager: Portage-2.3.69, Repoman-2.3.16 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.69.ebuild | 260 +++++++++++++++++++++++++++++++++ 2 files changed, 261 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97c3ce41a76a1e214d6d341b8f8d4c7e94785423 commit 97c3ce41a76a1e214d6d341b8f8d4c7e94785423 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-07-11 04:13:33 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-07-11 04:14:49 +0000 app-portage/emerge-delta-webrsync: Bump to version 3.7.6 #689072 default repo.conf sync-openpgp-keyserver to hkps://keys.gentoo.org in order to prevent key poisoning for sys-apps/portage[rsync-verify] #689506 default repos.conf sync-webrsync-verify-signature for sys-apps/portage[rsync-verify] Bug: https://bugs.gentoo.org/689072 Bug: https://bugs.gentoo.org/689506 Package-Manager: Portage-2.3.69, Repoman-2.3.16 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-portage/emerge-delta-webrsync/Manifest | 1 + .../emerge-delta-webrsync-3.7.6.ebuild | 43 ++++++++++++++++++++++ 2 files changed, 44 insertions(+)
We now have secure key refresh by default in stable sys-apps/portage-2.3.69 (bug 690950) and app-portage/emerge-delta-webrsync-3.7.6 (bug 690952).
