By Rainer Wichmann rainer@
la-samhna.de (last update: Nov 10, 2003)Attackers will always search for, and exploit, the weakest part of a system. With respect to open source software, the weakest part is often the software distribution. This is a short guide explaining the problem, and showing how you can protect yourself.
The problem with open source software distribution
There are plenty of open source software applications available, and most (or all) of them are distributed via FTP or web servers to interested users. Unfortunately, sometimes a server gets hacked by malicious intruders, and the software available on the server is then replaced by a trojanized version.
If you then download, compile, and install such a trojanized version of the original software, a secret backdoor may get installed on your computer that allows unauthorized access to an intruder.
Incidents
The attack discussed here is far from theoretical. In the past, there have been quite a number of attacks using this method, often targeted at high-profile software that would be downloaded by a large number of people:
- wu-ftpd CERT Advisory CA-1994-07
- ircii CERT Advisory CA-1994-14
- TCP Wrappers CERT Advisory CA-1999-01
- util-linux CERT Advisory CA-1999-02
- AIDE Announcement on mailing list
- OpenSSH CERT Advisory CA-2002-24
- sendmail CERT Advisory CA-2002-28
- tcpdump/libpcap CERT Advisory CA-2002-30
How can you protect yourself ?
If you plan to use some open source software downloaded from the internet, you should always verify the integrity of this software before you try to compile and/or install it.
It is important to realize that a checksum, e.g. an MD5 checksum, of a software packet is useless, unless you have obtained this checksum from an independent source (i.e. not from the same - potentially hacked - server from which you have downloaded the software).
The reason is that anybody can compute the checksum of any file. In particular, a malicious intruder can of course compute the checksum of his/her trojanized version of the original software, and place it on the hacked server.
PGP signatures
PGP signatures are cryptographic signatures created with a secret key that is only known to the key owner, e.g. the original author of a signed software packet. It can therefore not be forged by anyone else. If the signed file has been modified after creating the signature, the signature will not be valid anymore, i.e. signature verification will fail.
A secret PGP key has a corresponding public PGP key that can be used to verify the signature. Public keys are usually published on key servers. Most key servers are synchronizing among each other, i.e. each key can be downloaded from any key server you like, e.g. pgp.mit.edu or blackhole.pca.dfn.de.
Verifying a PGP signature
GnuPG is a well-known and popular program to create PGP signatures and/or verify them. Extensive online documentation (Howto, User Guide) for GnuPG is available via the GnuPG Documentation Page. Using GnuPG to verify a signature is rather trivial (normally, the signature is in a separate file whose name ends with .sig or .asc):
gpg --verify signature signed-file
Let's look at a real-life example, where we try to verify the integrity of the tct software package (tct-1.07.tar.gz), using the signature tct-1.07.tar.gz.sig downloaded from the same web site. We use the option '--keyserver blackhole.pca.dfn.de' to tell GnuPG from which keyserver the required public key should be downloaded, if it is not already in our public keyring (the collection of public keys locally stored):
/usr/local/src$ gpg --verify tct-1.07.tar.gz.sig tct-1.07.tar.gz
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Mon May 14 19:19:24 2001 CEST using RSA key ID D5327CB9
gpg: Can't check signature: public key not found
/usr/local/src$ gpg --keyserver blackhole.pca.dfn.de --recv-keys D5327CB9
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: key D5327CB9: public key "wietse venema " imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
/usr/local/src$ gpg --verify tct-1.07.tar.gz.sig tct-1.07.tar.gz
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Mon May 14 19:19:24 2001 CEST using RSA key ID D5327CB9
gpg: Good signature from "wietse venema "
gpg: aka "wietse venema "
gpg: checking the trustdb
gpg: no ultimately trusted keys found
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 78 96 4A 4D F0 F0 D1 3C 45 E9 03 FC 17 67 DC D8
The output from GnuPG shows that:
- the software package has been signed on May 14, 2001 by a key with the ID D5327CB9 and the fingerprint "78 96 4A 4D F0 F0 D1 3C 45 E9 03 FC 17 67 DC D8"
- the owner of that key claims to be "Wietse Venema", and
- GnuPG does not know whether this key really belongs to Wietse Venema
So we have verified that the downloaded software has a valid signature, i.e. it has not been altered or modified after this signature has been made. However, we still do not know who has created this signature - was is the original author (Wietse Venema), or was it just someone claiming to be Wietse Venema ?
Verifying the owner of a PGP key, or: should you trust that key ?
PGP keys can be certified. This means: someone looks at the ID card (or a similar document) of the key owner, verifies that the key owner really is who (s)he claims to be, and certifies this by signing the key with his/her own key.
Thus, for judging whether you can trust a key, there are basically two options:
- you have met the key owner, and verified his/her identity, or
- the key is signed by someone that you trust.
Actually, if you have keys in your keyring that you have marked as
'trusted', GnuPG will automatically check whether a new key is
signed by a trusted key. In practice, you would need a fairly large
'web of trust' for this to work for some random key ...
In order to
view the signatures of a key, you can use:
gpg --list-sigs key ID
However, you will only see the key IDs of the signees, not their names, unless you have their keys already in your keyring, as you can see in the following example (abbreviated):
gpg --list-sigs D5327CB9
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
pub 1022R/D5327CB9 1992-09-25 wietse venema
sig D304CCB7 1999-01-22 [User id not found]
sig 4413B691 1999-02-17 [User id not found]
sig 2011B879 1998-10-23 [User id not found]
sig A88C28D0 1999-01-22 [User id not found]
sig E88EF71F 1999-05-06 [User id not found]
sig DC736337 1999-04-05 [User id not found]
sig 270076FD 1998-10-23 [User id not found]
sig 09590CFD 1998-10-22 [User id not found]
sig 2B4C654E 2000-04-10 [User id not found]
sig C4A96225 1998-04-20 [User id not found]
sig D5327CB9 1998-02-05 wietse venema
sig 17229EB2 2000-05-10 [User id not found]
sig 669B7C6B 1998-10-29 [User id not found]
...
Most keyservers have a WWW interface that lists more details
for the signatures on a key, such as the names of the signees
(use the 'verbose index' option on the WWW interface).
The most detailed information is provided by keyservers using the
SKS keyserver software.
Ultimately, it is your own decision whether you trust a key or not.
What if the software package is not signed ?
Contact the author/developer. Explain him/her why this is a BadThing(tm), and ask him/her (politely !) to sign his/her software.
Or, if you really know what you are doing, investigate the source code to check for back doors ...
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Germany License.