S 4.177 Assuring the integrity and authenticity of software packages

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Change Manager, Administrator

Considerable damage can be caused by carelessly executing programs originating from "insecure" sources. Malicious software (referred to as malware), for example, could install programs to spy on passwords, Trojan horses, or backdoors on a computer, or simply alter or delete data.

Examples of typical sources of such malware include programs that pretend to be a screen saver, virus scanner, or other utility program and that then send emails to a large number of recipients using a faked sender address. Incautious users often download programs from the Internet and install them without checking them first.

Two examples in which damage could have been avoided by examining the existing digital signatures include an incident in March of 2002 when the distribution of the OpenSSH package on the FTP server of the OpenSSH project was manipulated, and a similar incident in September of 2002 when the same was accomplished with the distribution of the sendmail mail server. In both cases, Trojan horses that could have lead to the compromising of the computers on which the packages were compiled were smuggled into the distributions. In both cases, examination of the existing digital signatures would have lead to the detection of the manipulations to the software.

If encryption or signature methods are not in use, then their use should be considered to the extent described in this safeguard.

As a general rule, only software from known sources should be installed, especially when the software is not delivered on data media and is downloaded from the Internet instead, for example. This applies especially to updates and patches, which are not usually delivered on data media anymore. Most manufacturers and distributors provide checksums for this purpose that at least allow you to verify the integrity of a package. The checksums in this case are usually published on the website of the manufacturer or may be sent by e-mail. To verify the integrity of a program or archive file that was downloaded, the published checksum is compared to a checksum generated locally by a corresponding program.

If checksums are provided for a software package, then they should be used to verify the software package before it is installed.

Note though that it is impossible to verify the authenticity using checksums. For this reason, digital signatures are offered for programs or packages in many cases. The public keys needed to verify the digital signatures are usually provided on the website of the manufacturer or made available on public key servers. The checksums are frequently generated using the PGP or GnuPG program.

If the check performed verifies that the signature is a valid signature of the manufacturer, then the resulting level of trustworthiness in the package is significantly greater than in cases where only the checksum is verified.

The RPM (RedHat Package Manager) package management system commonly supplied in Linux distributions and the package management system for the Debian distribution both come with a verification functionality already integrated.

Sometimes, even the integrated software update mechanisms of the respective operating system or the application software do not carry out checksum comparisons. However, the checksum of every software package should be checked before it is installed, if possible.

In addition, checksum comparisons sometimes require the user's participation, as the manufacturers do not provide the required checksums, signatures or certificates in a uniform manner. Manual verification on the manufacturer's website or URL adaptation in the patch and update software is therefore often required.

If digital signatures are available for a software package, then the signatures should always be checked before installing the package.

A general problem when using digital signatures is verifying the authenticity of the key used. If a public key does not bear a signature from a person or organisation who is known to be trustworthy (i.e. a trust centre), then the signatures generated with the corresponding private key do not offer any real security that the software package actually came from the developer, manufacturer, or distributor. For this reason, the public keys should be obtained from a source other than the software package itself, if possible, unless the keys are certified (i.e. from a CD-ROM provided by the manufacturer, from another mirror server from which the package can be downloaded, or from a public key server).

To verify checksums and digital signatures, the corresponding programs must be available locally on the computer. The administrators should know of the importance and validity of checksums and digital signatures. Furthermore, administrators need sufficient time to use the respective programs for their daily work and to learn how to operate them.

For various reasons, patches and changes should not be obtained by e-mail. The origin of e-mails is difficult to determine without additional security mechanisms and the recipient addresses in organisations are often mailing lists whose address is easy to guess. Also, patches and changes may nowadays be very large. Many companies and authorities limit the size of e-mail attachments and sometimes prohibit the receipt of executable attachments. In addition, large amounts of data unnecessarily burden the e-mail systems. Therefore, e-mail does not sufficiently guarantee timely availability of the software changes which may be critical with security patches in particular.

Some manufacturers additionally offer to send changes and patches directly to the customer using data media. In this case, patches and changes should also be verified using checksums or digital signatures, if possible, as information on senders on mail as well as manufacturer logos on CDs and DVDs can be easily faked.

Messages published on the manufacturer's website, in the newsletter or similar channels may also help to check the authenticity of an update. Some manufacturers have established cycles and times for systematic publication of information on changes.