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.
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:
$ echo 'subscribe announce' | mail firstname.lastname@example.org $ echo 'subscribe security-announce' | mail email@example.com
If you would rather receive mail on a different machine, send the following
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
firstname.lastname@example.org; for help on using
echo 'help' | mail email@example.com)
Also in Securing Small Networks with OpenBSD:
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.
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
they are always available in the top directory for the release you are
using. For OpenBSD 3.2, descend into
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.)
Next, move the source archives to the
$ sudo mv ./XF4.tar.gz /usr/src $ sudo mv ./ports.tar.gz /usr/src $ sudo mv ./src.tar.gz /usr/src $ sudo mv ./srcsys.tar.gz /usr/src $ cd /usr/src
and unpack them with:
$ sudo tar -zxvf *.tar.gz
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
pub/OpenBSD/patches/3.1. Download the
3.1.tar.gz archive into your home directory and unpack
$ tar -zxvf 3.1.tar.gz
You will now have a directory named 3.1 with the following subdirectories:
alpha/ amiga/ common/ hp300/ i386/ m68k/ mac68k/ macppc/ mvme68k/ ports/ sparc/ sparc64/ vax/
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
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:
$ sudo patch -p0 < /home/joe/3.1/common/004_sshbsdauth.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |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 | |Index: usr.bin/ssh/auth.c |=================================================================== |RCS file: /cvs/src/usr.bin/ssh/auth.c,v |retrieving revision 1.41 |diff -u -r1.41 auth.c |--- usr.bin/ssh/auth.c 19 Mar 2002 15:31:47 -0000 1.41 |+++ usr.bin/ssh/auth.c 22 May 2002 20:28:25 -0000 -------------------------- Patching file usr.bin/ssh/auth.c using Plan A... Hunk #1 succeeded at 410. done $ ...
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:
$ cd usr.bin/ssh $ sudo make obj $ sudo make cleandir $ sudo make depend $ sudo make && make install
Now we need to stop all
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
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
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.
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.
Read more Securing Small Networks with OpenBSD columns.
Return to the BSD DevCenter.
Copyright © 2009 O'Reilly Media, Inc.