Patching OpenBSD

OpenBSD 3.2 is with us, and it's time to upgrade our systems to the
latest release. As usual, it is strongly suggested that you install the
latest release on a spare machine, apply patches, and test it until you
are happy with what the OpenBSD gang gave us. Only then you should
upgrade and patch the production machine. But how do you patch
OpenBSD?

Patching is something that any OpenBSD administrator ought to do as
soon as patches are available, because leaving your system unpatched is
simply asking for trouble. OpenBSD and OpenSSH have recently become
targets for hackers looking for new fields to explore, and we all need to
be on guard.

How Do I Know That a Patch Has Been Released?

If you are not yet subscribed to the announce and
security-announce mailing lists, do it now. Assuming that your
machine is properly configured, and can send and receive mail, you can
subscribe to these lists from the command line:

If you would rather receive mail on a different machine, send the following
message to majordomo@openbsd.org:

subscribe announce
subscribe security-announce
--

(If you are curious to know what other mailing lists are available on
the openbsd.org server, use echo 'lists' | mail
majordomo@openbsd.org; for help on using majordomo,
use echo 'help' | mail majordomo@openbsd.org)

Subscribing to these list will help you track patches released from the
moment you subscribe, but you also need to check if there were any patches
released before you subscribed. Also, the announcements are just that --
announcements; you need to download the patches yourself. The list of
patches for the current and previous releases of OpenBSD can be found on
the OpenBSD errata
page.

Note that the OpenBSD team only supports the current and the previous
releases of the system. For example, after OpenBSD 3.2 was released,
patches are only issued for OpenBSD 3.1 and 3.2, but not for OpenBSD 3.0
or earlier releases. Also remember to apply patches in the same order in
which they are issued.

To apply patches, you will need access to the sources of the OpenBSD
release you installed on your machine. These are the sources that have
been used to build that release of OpenBSD, not the CURRENT sources held
in CVS. Strictly speaking, they are in CVS, but extracting them from
there would take the uninitiated users too much time and effort.

Where Are the Sources?

The official archives of sources for each release are available on the
original OpenBSD CD-ROMs
or on-line from many OpenBSD FTP
mirror servers. If you are downloading them with ftp,
they are always available in the top directory for the release you are
using. For OpenBSD 3.2, descend into pub/OpenBSD/3.2 and
download these files:

XF4.tar.gz
ports.tar.gz
src.tar.gz
srcsys.tar.gz

(Please use the FTP mirror at
a location closest to you to save bandwidth.)

Where Are the Patches?

Once you have the OpenBSD sources, you will need to download the
patches. The latest set of patches is always available on the FTP mirror servers in the
subdirectories of the pub/OpenBSD/patches directory. For
example, if you are looking for patches for OpenBSD 3.1, you will find
them in pub/OpenBSD/patches/3.1. Download the
3.1.tar.gz archive into your home directory and unpack
it:

$ tar -zxvf 3.1.tar.gz

You will now have a directory named 3.1 with the following
subdirectories:

Out of these subdirectories, only three are of interest to us:
common (contains patches for all hardware platforms),
ports (contains patches for the ports collection, applicable
to all hardware platforms), and the subdirectory containing patches
applicable to the hardware platform you use. For Intel x86 machines, we
need the patches from i386/.

How Do I Apply Patches?

Every patch comes with detailed instructions on how you should apply
it, so the first step is reading them:

$ less /home/joe/3.1/common/004_sshbsdauth.patch
Fix a bug in the BSD_AUTH access control handling
Apply by doing:
cd /usr/src
patch -p0 < 004_sshbsdauth.patch
cd usr.bin/ssh
make obj
make cleandir
make depend
make && make install
...

As you can see, we are told to change the present working directory to
/usr/src and apply that patch:

What happens next depends on the commands listed in the Apply by
doing: section. In case of 004_sshbsdauth.patch for OpenBSD
3.1 shown above, we need to execute some additional commands to create new
binaries from patched sources:

Now we need to stop all ssh/sshd processes and
restart them to make sure that the system and users use new binaries. (If the
patch contains additional instructions, obey them.) Once we are happy that
everything is working fine, we can copy new binaries to the production
machine.

How do we know which binaries have been modified? The output from
make install contains a list of binaries and other files
changed during compilation. Make a list of their locations, ownership,
and access rights. Then use scp to copy them to the
production machine. (You may have to copy them to a temporary location.)
Then log onto the production machine, become superuser with
su, replace old binaries with the new ones, and restart the
relevant processes. (You must stop them first; merely restarting them
with kill -HUP may not be enough.) A system reboot is not
out of place in case of more extensive changes. Of course, it needs to be
done at times when it will cause the least inconvenience to users. Use
your judgment to decide what needs to be done and when best to do it.

When Not to Patch?

You do not have to apply all patches. Patches issued for hardware
platforms you do not use or for ports you do not install can be ignored.
All others ought to be applied as soon as you learn about them.

Until next time.

Jacek Artymiak
started his adventure with computers in 1986 with Sinclair ZX Spectrum. He's been using various commercial and Open Source Unix systems since 1991. Today, Jacek runs devGuide.net, writes and teaches about Open Source software and security, and tries to make things happen.