Patching OpenBSD (zt)

cobrawgl

1.Patching OpenBSD
http://www.oreillynet.com/pub/a/bsd/2003/01/16/ssn_openbsd.html

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.org

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.)

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/src

and unpack them with:

$ sudo tar -zxvf *.tar.gz

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:

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 install

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 is a freelance consultant, developer, and writer.