Kurt Seifried Security Advisory 001 (KSSA-001)

Created by Kurt Seifried, [email protected]

• Advisories
• Anti-virus
• Articles
• Basic security
• Best practices
• Books
• Cryptography
• Intrusion Detection
• Encryption keys
• Network
• Operating system
• Policy
• Ports
• Products
• Social
• Technical
• Weekly column
• WWW authentication
• Main page
• Back

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 [email protected]

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 ([email protected]) 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 "[email protected]" 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, "[email protected]"
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):

[[email protected] /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":

[[email protected] /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 <[email protected]>"
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 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 Kurt Seifried, and provided such reproduction and/or distribution is performed for non-commercial purposes.

Any other use of this information is prohibited. Kurt Seifried is not liable for any misuse of this information by any third party.

Last updated 4/10/2001

Copyright Kurt Seifried 2001