SecurityPortal Security Advisory SPSA-2001-0001
http://www.securityportal.com/articles/advisory20010001.html
Title:
RPM PGP/GnuPG verification bug
Issue date:
Feb 27, 2001
History of advisory:
Feb 23, 2001 Ben De Rydt (ben dot de dot rydt at pandora dot be) brought this to
my attention.
Feb 27, 2001 advisory written and released to Linux vendor list, vendors
notified.
Feb 28, 2001 updated, thanks to Olaf Kirch for mentioning automatic key
downloads.
Author:
Kurt Seifried seifried@securityportal.com
Credits:
Ben De Rydt (ben dot de dot rydt at pandora dot be) originally brought this to
my attention, thanks go to him.
Olaf Kirch (okir@caldera.de) for mentioning automatic key downloads and macros
(which I read in the man page but mentally skipped over).
Overview:
There is a significant implementation/logic bug in how RPM verifies the
cryptographic signatures on RPM files.
Vendor Contact:
N/A
Impact:
An attacker can create RPM's that will appear to be legitimate to the
administrator, once installed root access (or anything else) can easily be
achieved.
Details:
If an attacker can trick an administrator into installing an RPM checking the
signature on the RPM can easily be subverted, thus the trojan'ed RPM is
installed and the attacker can gain access.
If an attacker can trick an administrator into installing a new key, or the
administrator has enabled automatic key downloads, and provide them with a
trojan'ed rpm file they can gain root access. No local access is required.
Getting an admin to install a new key can be as simple as posting fake keys with
identities like "secure@vendor.foo" or by simply emailing them to administrators
with a subject line such as "new vendor key, please use to verify future rpm
packages". Getting the administrator to download trojan'ed packages is
attainable by poisoning DNS, spoofing a site, or breaking into a major RPM ftp
site.
1) Attacker creates fake key, "secure@vendor.foo"
2) Attacker creates trojan'ed RPM, signs with fake key
3) Attacker sends key to victim, via email or otherwise, or victim has
"automatic key download" enabled (note: it is common for vendors to send out
self signed keys on various mailing lists)
4) Attacker either spoofs an update site, or breaks into a legitimate update
site, replaces the real RPM with their trojan'ed RPM
5) User downloads RPM, verifies it (examples sanitized):
[root@server /root]# rpm -K gnupg-1.0.1-1.i386.rpm
/root/RPMS/gnupg-1.0.2-4.i386.rpm: md5 gpg OK
Even with an "rpm -Kvv":
[root@stench /root]# rpm -Kvv /root/RPMS/gnupg-1.0.1-1.i386.rpm
D: New Header signature
D: Signature size: 149
D: Signature pad : 3
D: sigsize : 152
D: Header + Archive: 709097
D: expected size : 709097
/root/RPMS/gnupg-1.0.2-4.i386.rpm:
MD5 sum OK: 005707d7f35fc754dc5402462caf2ef6
gpg: Signature made Wed 30 Aug 2000 04:14:57 PM MDT using DSA key ID DB42A60E
gpg: Good signature from "Vendor, Inc "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
gpg: Fingerprint: CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E
Please note that this is from a default install of a recent Linux distribution,
error messages such as "WARNING: This key is not certified with a trusted
signature!" are likely to be ignored (or they may have signed the attackers fake
key).
Unless the user checks the fingerprint of the key against a known good list (the
key ID is not resistant to collision and can be faked) they will be none the
wiser that this is an attackers key and RPM, and not a legitimate vendors.
Due to the burden placed on the victim by this attack it is considered unlikely
(unless of course automatic key downloads are enabled, in which case it is
significantly easier) that widespread attacks based on it will happen. However
an internal attacker, using this technique, does stand a good chance of
leveraging access to other machines if the administrators are not sufficiently
careful. This also underscores the need to provide users with more information
when verifying cryptographically signed data, and the importance of securely
storing keyrings.
Solutions and workarounds:
Disable automatic key downloads if they are enabled.
Ideally you should create a seperate keyring with only the vendor keys on it to
verify rpm's. Add the following lines to /etc/rpm/macros:
%_signature gpg
%_gpg_path /etc/rpm-keys/
In this example the files:
options
pubring.gpg
secring.gpg
trustdb.gpg
will be placed into the directory /etc/rpm-keys/. Using rpm to verify packages
will result in this keyring being used, and not root's default keyring.
Do not install additional keys into root's keyring or the system one used to
verify RPM's, and protect this keyring. Verify through a trusted channel any new
vendor keys (e.g. many vendors now place them on distribution CD's). You can
protect root's or the system keyring with the simple expedient of setting it
read-only or immutable (on ext2):
# chmod a-w /root/.gnupg/pubring.gpg
or
# chattr +i /root/.gnupg/pubring.gpg
This will prevent accidental or casual insertion of new keys. If you have many
keys in either keyring you should make sure to verify the fingerprint every time
you check a package's signature.
Vendors that ship RPM update tools should use a separate keyring (instead of
root's) for verifying RPM's that are downloaded.
References:
[man page] rpm(8)
[url] http://www.rpmdp.org/
--------------------------------------------------------------------------------
Permission is granted for copying and circulating this Bulletin to
SecurityPortal (SP) customers (or the Internet community) for the purpose of
alerting them to problems, if and only if, the Bulletin is not edited or changed
in any way, is attributed to SP, and provided such reproduction and/or
distribution is performed for non-commercial purposes.
Any other use of this information is prohibited. SP is not liable for any misuse
of this information by any third party.