In Microsoft made Firefox vulnerable; Mozilla responds, I explained the recent state of affairs for a Microsoft update from early this year that altered the way Firefox works without informing users. That led to a .NET vulnerability affecting Firefox just as much as it did Internet Explorer. The Think Security article, Update Cautiously, describes two more such incidents with very wide-ranging effects that will be remembered for years to come: the patches for the vulnerability targeted by the SQL Slammer worm that uninstalled themselves, and the MS Windows XP Service Pack 1 deployment that killed the functionality of a lot of important software.

There are not too many people arguing that installing security updates for software quickly is a bad idea, in general. Still, avoiding these pitfalls in software requires caution in how software updates are researched and deployed. Even for single-user home desktop computers, researching updates before installing them, and refusing to install particular updates altogether — such as the .NET update that made Firefox vulnerable, if you do not actually use any .NET software — is an important part of computer security strategy.

Some software developers and distributors, particularly if they are large corporate software vendors such as Apple and Microsoft, take the position that they know best and users should generally just let the vendor decide what updates get applied, and when they get applied. For those who are, for whatever reason, incompetent to make decisions about their own software and do not have someone more technically inclined available to handle software updates for them, just taking the vendor’s word for it may be better than the alternative. For those of us who are technically inclined and interested in the security of our computers and the data we store on them, however, every single update should be at least minimally researched before being applied.

Of course, keeping backups of everything on the system is the most comprehensive way to allow one the opportunity to recover from unexpectedly damaging changes. If you have the ability to maintain such backups, make sure you have fresh backups just before performing software updates. Even better than being able to roll back a change that breaks the smooth operation of the system, however, is preventing the problem from occurring in the first place.

Certain operating systems make this easier than others, as do certain applications. FreeBSD in particular offers specific explanations of gotchas and difficulties that might affect users when software is updated, and also makes it easy to audit installed software for vulnerabilities. In cases where a test network and the resources of research in depth are unreasonable expectations, the key to ensuring upgrades go smoothly without breaking things is to have a step by step process for updating that makes minimal research easy to perform and directions for solving updating problems before they affect your system easy to find and follow. Thanks to the UPDATING notes provided by the FreeBSD Ports system, such a process is easy to develop.

The way I handle software updates on FreeBSD starts when I install FreeBSD. Once the OS is installed, I also install the /usr/ports/ports-mgmt/portupgrade port. This is a set of scripts that automate and simplify the user interface to the Ports system. You can read more about it and how to get it set up in the FreeBSD Handbook. Next, I use the portinstall command provided with portupgrade to install the portaudit tool. You can find information about it, too, in the FreeBSD Handbook.

Then, every time I need to update software, I follow a procedure that looks something like this:

  1. Enter portsnap fetch update to update the local Ports tree snapshot.
  2. Enter portaudit -Fa. The -F option fetches the current portaudit database. The -a option prints a vulnerability report for any software installed from ports that have known vulnerabilities.
    • If the portaudit command indicates any vulnerabilities, open the /usr/ports/UPDATING file in a pager or text editor. I typically use less in a terminal emulator. Use the pager’s or editor’s text search capabilities to search for any references to the vulnerable port in the UPDATING file dated on or after the date of the last time you updated your system’s software.
    • If any vulnerable software is found in the UPDATING file with special updating instructions, follow those directions except in cases where the instructions require me to recursively update other software. In those cases, make a note of what needs to be done for later, and hold off on following those directions for now.
    • If no vulnerable software is found in the UPDATING file, just use portupgrade to update those specific vulnerable ports normally.
  3. Enter portversion -vL=. The portversion utility is used to compare installed versions of software with those in the current Ports tree. The -v turns on verbose output. The -L option, with = as an argument, excludes any installed software whose status flag is =, thus only showing software with newer versions in the current Ports tree (or, conceivably, with older versions in case of a roll-back).
    • Perform the same steps for any ports listed by portversion -vL= as you did for portaudit’s output, checking them against the UPDATING file, following directions, and making note of those whose directions need to be followed separately later because they will recursively update other ports.
  4. Follow the directions for the ports that require recursive upgrades or recompiling of additional ports at this point. The reason you would want to hold off until this point is so that, when following those directions, you will not inadvertently upgrade a port that requires special handling as described in the UPDATING notes before you get the chance to follow those directions.
  5. Finally, if there are any ports left that need updating, you can upgrade them all with the portupgrade -a command. The -a option tells portupgrade to operate on all installed packages that are not up to date.

Occasionally, you may find that a port does not want to upgrade because of the existence of an earlier version. This should usually mean you forgot to do something explained in /usr/ports/UPDATING, but sometimes even after doing all the special software upgrade handling indicated, this may occur with an error telling you that you could try uninstalling and reinstalling the port in question. To do so for the Firefox 3.5 port, for instance, you could do the following:

cd /usr/ports/www/firefox35 make deinstall make reinstall

Just to be perfectly safe, however, you should ensure that the files listed in /var/db/pkg/firefox-3.5.4,1/+CONTENTS are backed up somewhere so you can restore them later. Thus if, for some reason, the make deinstall works but the make reinstall does not, you have a way to get your previously working copy of Firefox 3.5 back.

An example of how this works in your favor is the update of the Perl interpreter in September of this year. Because it is a programming language interpreter, and many basic utilities on most Linux distributions and BSD Unix systems are written in Perl, a change to the Perl interpreter can lead to considerable grief later on. If some utility depends on a particular assumption of how the Perl interpreter works that has changed with the latest update to it, the utility may stop working.

The /usr/ports/UPDATING file had this to say about updating Perl this September:

20090911: AFFECTS: users of lang/perl5.10 AUTHOR: [email address removed] lang/perl5.10 has been updated to 5.10.1. You should update everything that depends on perl. The easiest way to do that is to use "perl-after-upgrade" script supplied with lang/perl5.10. Please see its manual page for details. If you want switch to lang/perl5.10 from lang/perl5.8 please follow instructions in the entry 20090328 in this file.

Unfortunately, many OSes lack something like FreeBSD’s UPDATING notes, or any software version upgrade notes are less oriented toward giving the user helpful information for easing the pain of updating. In some cases, such as that of MS Windows, the only software that is covered in any software update notes is software produced by the vendor, and even that may be obfuscated or left incomplete as in the case of the Firefox vulnerability created by a software update from Microsoft this year.

In these cases, more time should be spent in research outside of the information provided by the software distributor itself than would otherwise be necessary. Google can be your friend at such times, when you seek to make software upgrades as smooth and painless as possible.