Writing Security Advisories: The Good, the Bad and the Ugly

I’ve been writing security digests now for several months, for Linux and BSD. This means I read pretty much every single vendor-issued security advisory, along with advisories for software packages on Bugtraq and other mailing lists/Websites/etc. I am happy to say that most Linux distributions and vendors are doing a pretty good job on their security advisories, but not all are perfect. A security advisory is a complex thing to write properly. The following items need to be covered (if applicable).

• Name of the problem.

• Description of the problem, severity, etc.

• Versions affected and not affected, configurations affected and not affected.

• Workarounds for the problem.

• Solutions for the problem.

• List of software updates to apply.

• Where to get the software updates.

• How to apply the software updates.

• Patch code.

• Contact information in case you have more questions.

• URL for the advisory (i.e. FTP or WWW).

There are a number of other optional items that are worth consideration, such as giving credit to the person(s) who discovered the problem originally, came up with the fix, and so on. Giving credit costs nothing, and encourages people. The advisory should also be signed securely. PGP or GnuPG are good choices for this. X.509 signing is not such a good idea since these advisories should be posted to Web and FTP sites in addition to mailing lists. Unfortunately, most PGP-signed advisories that are emailed get sufficiently mangled (line wraps), so when you check the advisories, they say something like:

*** PGP Signature Status: bad
*** Signer: Name removed to protect the innocent
*** Signed: 8/30/00 3:38:25 AM
*** Verified: 9/2/00 1:53:14 AM
*** BEGIN PGP VERIFIED MESSAGE ***

And since many do not include a link to the advisory via FTP or WWW, most users will not bother to check the validity of the advisory. It is only a matter of time before some adventurous soul posts a fake advisory which people follow, loading Trojan code. This is especially true for non-vendor advisories, i.e. advisories for the smaller software packages. For example, Helix Code issued a security advisory recently that was not PGP/GnuPG-signed. Hopefully, if enough vendors follow these practices, users will become used to actually verifying the validity of security announcements, and will not be as easily fooled.

This leads to my next point. PGP/GnuPG keys: would it be too hard to have them signed properly and posted in an easy-to-find location on the Web? Caldera is especially guilty in this respect. I could not find their PGP key on their Website. When I searched the key servers I found several, but since their keys are not signed by any other keys (self-signed: absolutely useless), they are of questionable value. Shame on Caldera. Vendors should get together and at least sign each others’ keys, and maybe get luminaries such as Linus Torvalds or Werner Koch (author of GnuPG) to sign their keys.

The next problem area is advisory numbers. Most vendors put a unique advisory number on each advisory. Most use something along the lines of:

vendor_id_sa-number-version

CSSA-2000-029.0
MDKSA-2000:042
RHSA-2000:047-03 

CS is Caldera Systems, MDK is Mandrake, RH is Red Hat, and so on. The SA stands for Security Advisory. The year is a really good idea. A whole number, of course, would be pointless without the version number, and not having a revision number is highly annoying when trying to figure out which is the latest (i.e. correct) version of the advisory. (Do not “backport” updates to advisories and neglect to add a revision number – this is a really bad idea.) This information is critical for your users. You need to make it as understandable as possible and extremely easy to keep track of. Some vendors guilty of not using advisory numbers include SuSE and Debian, with things like:

Update: the powerpc packages mentioned in the first release of this advisory were linked with a version of libgtk that is not available in Debian GNU/Linux 2.2. They have been recompiled with the correct version and reuploaded.

Now for my all-time favorite pet peeve: not listing MD5 sums in the advisory along with the software packages. It’s trivial to execute “md5sum *” and cut and paste that into an advisory. Luckily, most vendors include MD5 sums in their advisories (most of the smaller software packagers do not). However, in some cases the MD5 sums listed and the actual MD5 sums of the software packages have been different – meaning someone messed up while creating the advisory, or the packages have been replaced with a different version on the FTP site.

Between most posted security advisories not being verifiable by the PGP/GnuPG signatures, and the occasional MD5 sum mistake, it is very difficult for users to verify packages. Of course, if vendors signed their packages, it would basically be a non-issue. Currently many major vendors do not PGP/GnuPG-sign their packages, although SuSE and Mandrake should be doing this in the next major release.

There are often other problems with security advisories that make them hard to read or interpret. One of the most annoying things is to read a security advisory with spelling mistakes in it. It really makes me wonder how much care and attention was spent on the security problem that is being talked about. Another issue is listing updates “messily” – that is, having multiple product versions with different updates, and a full pathname that is either not given or not very descriptive.

This brings us to the last and final problem: no matter how well an advisory is written, how technically accurate it is, and how well it walks the user through the update, it is absolutely useless if the user does not see it. Probably the best method for getting this information to users is to email it to them. Almost all Linux distributions have severity announcement mailing lists that they post all their advisories to. Many also post to lists such as Linux-Security-List and Bugtraq (the granddaddy of security mailing lists).

The advisories should also be posted to a directory on the vendor’s Website and FTP site. It requires a trivial amount of effort, but unfortunately many vendors do not place advisories in an obvious place, and even more do not include a URL to the WWW or FTP locations of their advisory.

All in all, most distributions are doing a pretty good job, but with a few improvements, they could be doing a great job. It should be interesting to see which distributions take this article to heart and change how they issue their advisories.