apt-key del silently fails to delete keys due to limited understanding of GPG key ID formats

[Evgeny Vereshchagin]

Description: Ubuntu 14.04.3 LTS
Release: 14.04

apt:
  Installed: 1.0.1ubuntu2.10

apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 7A82B743B9B8E46F12C733FA4759FA960E27C0A6

apt-key export 7A82B743B9B8E46F12C733FA4759FA960E27C0A6 # key is here

apt-key del 7A82B743B9B8E46F12C733FA4759FA960E27C0A6 # delete key

apt-key export 7A82B743B9B8E46F12C733FA4759FA960E27C0A6 # key is still here

# Works fine with IDs

apt-key del 0E27C0A6

apt-key export 7A82B743B9B8E46F12C733FA4759FA960E27C0A6 # nothing exported

# Works fine with fingerprint on Precise

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Moritz Naumann (mnaumann)]

I just ran into the same issue. What's not obvious from the original post, though, is that apt-key reports back that it deleted the key "OK" - but actually did not:

root@mybox:~# apt-key list | grep 79EAFD54
pub 1024D/79EAFD54 2009-01-22 [expired: 2013-06-28]

root@mybox:~# apt-key adv --keyid-format long --list-key 79EAFD54
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.0hGkImk1B8 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg --keyring /etc/apt/trusted.gpg.d/xorg-edgers-ppa.gpg --keyid-format long --list-key 79EAFD54
pub 1024D/BED1E87979EAFD54 2009-01-22 [expired: 2013-06-28]
uid security OBS Project <email address hidden>

root@mybox:~# apt-key del BED1E87979EAFD54
OK

root@mybox:~# apt-key list | grep 79EAFD54
pub 1024D/79EAFD54 2009-01-22 [expired: 2013-06-28]

As such, if you supply a key ID as an argument to "apt-key del" in any GnuPG supported format other than the 'old' short key ID format without leading "0x" (so just the last 8 bytes of the key's fingerprint, ") the result is that your command is *silently ignored*. (There seem to be some non-defined GPG formnats which will return an error message, such as when using the last 6 or 10 (but not 12) bytes of the fingerprint).

This can result in users and applications alike meaning to revoke trust on an APT archive keyring, being told they succeeded in doing so, but actually failing.

As such, from my perspective, this is a security bug.

This was Ubuntu 14.04.3 LTS x86_64 with the latest updates installed and no held packages (but some third party PPAs).

I have not tried to reproduce this issue on any other Ubuntu releases. I tried to reproduce this behaviour on Debian GNU/Linux 8.2 "Jessie" but was unable to.

[Moritz Naumann (mnaumann)]

This also affects Xenial (tested on yesterday's live installer).

[Michael Vogt (mvo)]

Attached is a fix for trusty based on the latest apt 1.10 apt-key.

Note that I was not able to reproduce this on xenial (and debian/sid) with apt 1.10.

[Brian Murray (brian-murray)]

I also was not able to recreate this on xenial.

[Seth Arnold (seth-arnold)]

Does this issue have a CVE assigned yet? Does it have a Debian bugreport yet?

Thanks

[David Kalnischkies (donkult)]

> Does this issue have a CVE assigned yet? Does it have a Debian bugreport yet?

It has neither and it needs neither in my humble opinion.

The longid issue had its own bugreport in Debian (#754436) which used the included patch (more or less) for Jessie while the 1.1 series (at that time already) had apt-key rewritten fixing this among other things. The unblock request back then mentions explicitly the inability of apt/jessie to work with fingerprints at the benefit of not introducing untested changes late in the release process.
As already mentioned 1.1 in Debian (and Ubuntu) supports fingerprints just fine, so there isn't anything left to be done for Debian.

In the end, "apt-key del" is supposed to be used only to get away from using apt-key as what you are supposed to be doing is ship your own -keyring package which contains a /etc/apt/trusted.gpg.d/ fragment file instead of using "apt-key add /path/to/file" to add your key to a central file (from which you have to delete it again on remove with "apt-key del"). I doubt the chances to have collision even with shortids among archive keyrings in the wild is high. With longids its even less likely. And what exactly is to be gained by such a collision given that all you get is to take another key (you collision with) with you at the time your maintainerscript (run with root rights I have to add) removes it…
[That "apt-key del" isn't failing and can't be changed to do it if it hasn't removed a key is btw based on the problem that its mostly called by maintainerscript, which don't ignore failures]

If on the other hand you happen to think you could revert a "apt-key adv" command like "--recv-key" with a "apt-key del" you are wrong as it isn't safe to fetch a key directly into an always trusted keyring to begin with (mainly as you can't be sure that gpg is actually inserting the key you wanted it to and no amount of fingerprint is helping here). See this subthread (and followups) for the written affirmation of Debians gnupg maintainer(s) that you can't: https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2015-August/002802.html [just so you don't have to "just trust me" on this].

So, in summary, I believe that the chance that you have a security bug on your(!) side based on the idea that you need a fingerprint in this scenario to interact with apt-key is a lot higher than the chance to encounter a collision even on short keyids in this scenario.

[Seth Arnold (seth-arnold)]

David, the CVE would be strictly for reporting "OK" to a delete command that did not actually delete anything.

When an admin tries to remove a trusted key, the tools should either report success when it does, or failure when it cannot.

I'm worried about the "apt-key adv --recv-key" issue; that's certainly not mentioned in the manpages the last few times I've used this. We should remove this advice from the manpage or provide a warning that it is not safe to use this, despite previous recommendations.

Thanks

[Videonauth (videonauth)]

Can confirm this is still apparent in 17.10 and affects me

[nivlac (carndt)]

Confirmed on xenial:

root@ubuntu:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.4 LTS"

root@ubuntu:~# apt-key list|grep -A3 ownCloud
uid ownCloud build service <obsrun@localhost>
sub 2048R/8DE365D9 2013-08-26 [expires: 2018-08-25]
sub 2048D/86EB6027 2013-08-26 [expires: 2018-08-25]
sub 2048g/1722EF54 2013-08-26 [expires: 2018-08-25]
root@ubuntu:~# apt-key del 8DE365D9
OK
root@ubuntu:~# apt-key list|grep -A3 ownCloud
uid ownCloud build service <obsrun@localhost>
sub 2048R/8DE365D9 2013-08-26 [expires: 2018-08-25]
sub 2048D/86EB6027 2013-08-26 [expires: 2018-08-25]
sub 2048g/1722EF54 2013-08-26 [expires: 2018-08-25]
root@ubuntu:~#

[Roman Fiedler (roman-fiedler-deactivatedaccount)]

Just as a side note:

1) apt-key via debootstrap is currently broken on Bionic anyway (gpgv1 to gpgv2 side effects probably), see https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1767319

2) apt-key seems to be deprecated and should not be used any more on newer systems, so maybe the bug is a good starter for enforcing deprecation after bionic: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060428.html

[Julian Andres Klode (juliank)]

Currently apt-key del can be called with a given key to remove it w/o having to check if it's in the database. Reporting an error would likely break existing packages.