Summary: | Poisoned keys may be used to cause denial of service on "emerge --sync" | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Hanno Böck <hanno> |
Component: | Auditing | Assignee: | Gentoo Security Audit Team <security-audit> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev-portage, k_f, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=689506 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 686768 |
Description
Hanno Böck
2019-07-01 11:19:30 UTC
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). |