Patching OpenBSD
by Jacek Artymiak01/16/2003
Welcome back!
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:
$ echo 'subscribe announce' | mail majordomo@openbsd.org
$ echo 'subscribe security-announce' | mail majordomo@openbsd.orgIf 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)
|
Also in Securing Small Networks with OpenBSD: Changes in pf: Packet Filtering |
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.)
Next, move the source archives to the /usr/src
directory:
$ 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/srcand unpack them with:
$ sudo tar -zxvf *.tar.gzWhere 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.gzYou 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 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:
$ 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 installNow 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.
Read more Securing Small Networks with OpenBSD columns.
Return to the BSD DevCenter.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 10 of 10.
-
Newbie Question
2003-11-14 13:24:48 rkersh [Reply | View]
This is probably a stupid question, but, do you have to unpack the sources everytime you apply a patch (i.e., delete everything in /usr/src and untar the sources)? Or, do you just keep applying the patches (in order) to the source you unpacked the first time?
-
Nice
2003-01-20 00:18:34 anonymous2 [Reply | View]
A well written article (yes yes, version number glitch aside). I wish I'd had something like this when I started!
I've had a lot of success with the binpatch subsystem for keeping my boxes up to date - you could really think o it more as an alternative to manually keeping lists of files to scp to your production boxes.
-
patches included in compiled packs
2003-01-19 23:17:11 bill_s [Reply | View]
I am new to openbsd, so this article was interesting and important for me.
What about file sets like base32.tgz, ports or packages. If I download one of them, are the latest known patches applied to them?
-
Version mixup
2003-01-19 07:43:19 anonymous2 [Reply | View]
Pathing 3.2 with 3.1 patches???
I don't think so. -
Version mixup
2003-01-19 08:07:20 Jacek Artymiak | [Reply | View]
I am not suggesting you should patch the 3.2 sources with patches for the 3.1 sources. But you are right, the "Where Are the Sources?" section should mention OpenBSD 3.1 instead of 3.2. My mistake, I should've caught that typo.
Jacek
-
when altq?
2003-01-18 07:47:32 anonymous2 [Reply | View]
few weeks ago you mentioned on deadly.org that you were preparing article on altq configuration, when it's going to be available? -
when altq?
2003-01-18 12:18:38 Jacek Artymiak | [Reply | View]
I'm finishing it (it grew into two parts) and the editor will be receiving it next week. -
when altq?
2003-01-18 09:42:03 coldiso [Reply | View]
seeing how altq has been merged with pf in --current you would probably want to check out
http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
search for QUEUEING. my hope is this will be ready for 3.3
If not, why would patch #12 of v 3.4 show the following?
Apply by doing:
cd /usr/XF4
patch -p0 < 012_font.patch
Then rebuild and install X:
cd /usr/obj
lndir /usr/XF4
make build
JQ