|
|
|
| Daemon News Ezine | BSD News | BSD Mall | BSD Support Forum | BSD Advocacy | BSD Updates |
Keeping FreeBSD Up-To-Date: A Security Odysseyby Richard Bejtlich (taosecurity at gmail dot com)
IntroductionAn important system administration task, and a principle of running a defensible network, is keeping operating systems and applications up-to-date. Running current software is critical when older services are vulnerable to exploitation. Obtaining new features not found in older applications is another reason to run current software. Fortunately, open source software offers a variety of means to give users a secure, capable computing environment. This article presents multiple ways to keep the FreeBSD operating system up-to-date. I take a FreeBSD 5.2.1 RELEASE system through a subset of security advisories to explain the different sorts of patches an administrator might apply. In a the next article I describe how to use the FreeBSD ports tree and related tools to keep non-OS applications up-to-date. I chose FreeBSD 5.2.1, released in February 2004, as my reference platform because it offers a security history suitable for describing multiple upgrade cases. At the time of writing FreeBSD 5.3 RELEASE is about a month old, and only two security advisories have been published thus far. Readers wondering why someone might want to install an "old" OS version can imagine that there might be an application supported only on FreeBSD 5.2.1 and not yet officially ready for 5.3, prompting an administrator to run a 5.2.1 box. All of the work done in this article was done remotely via OpenSSH. One danger of performing remote upgrades is losing connection during a critical phase of the process. One software-based way to deal with this issue is to conduct all remote upgrades within a screen(1) session. [1] Should you lose connectivity during the upgrade while running screen, your session will continue uninterrupted. The screen(1) program has suffered security problems in the past, so balance its features against the possible risks. My advice on administering this reference platform is based on deploying FreeBSD on servers, workstations, and laptops since 2000. The article represents mix of my interpretations of official FreeBSD documentation, inputs from mentors, and the result of my own experimentation and deployment strategies. This guide cannot be anywhere near a complete reference on keeping FreeBSD up-to-date or maintaining a secure system. I strongly recommend reading the excellent FreeBSD Handbook as well as the multiple helpful published books on FreeBSD.
FreeBSD VersionsBefore explaining ways to keep the FreeBSD OS up-to-date, I must briefly expand on the idea of the term "up-to-date." Thanks to FreeBSD's open source development methodology, any version of FreeBSD is available via check out from the Concurrent Versions System (CVS). [2] These versions can be represented by CVS revision tags. [3] The following examples begin with 5.3 RELEASE, the most recently published version of FreeBSD:
Linux users should note that these CVS revision tags do not pertain to the FreeBSD kernel alone. FreeBSD is developed as an integrated system, with a kernel matching userland tools. One should not run a kernel compiled for FreeBSD 5.3 RELEASE on a CURRENT machine. The kernel and all userland utilities are meant to be upgraded simultaneously, and must be kept synchronized. While Linux users are usually forced to acknowledge this good system administration practice when they upgrade major versions of their kernel (e.g., 2.2 to 2.4, or 2.4 to 2.6), they often maintain the same userland across minor kernel versions. FreeBSD strongly encourages users to always keep the userland and kernel in sync using the methods explained in the Handbook and elaborated upon in this document. When thinking of what it means to be "up-to-date," one can see that the "oldest" version of FreeBSD as of version 5.3 is that which was most recently "pressed to CD" -- RELENG_5_3_0_RELEASE or FreeBSD 5.3 RELEASE. The "newest" would be HEAD or CURRENT, a constantly moving target modified and improved on a daily basis. How does an administrator decide what to run on her machines? I prefer to begin a system's life by installing RELEASE software, like FreeBSD 5.3 RELEASE. As long as the systems performs as I would expect it to, I then track the RELENG_5_3 or "security" branch. This allows me to incorporate critical bug and security fixes that could jeopardize the system. Occasionally I may encounter a system that requires a feature (like supporting a new piece of hardware) not present in the RELEASE or security branches. In cases where that feature is supported by STABLE, I will upgrade to that branch. In the rare cases where not even STABLE has the feature I need, I might install a snapshot of the CURRENT branch. I do not recommend running CURRENT in production environments as it is not supported like the RELEASE or STABLE versions are.
Learning About Security IssuesFreeBSD security advisories are published at the FreeBSD security page and at the freebsd-security-notifications mailing list. [4,5] I recommend all FreeBSD users subscribe to the moderated, very low volume notification mailing list. The advisories provide background, a problem description, and impact statement, workaround advice, a solution to fix the problem, and correction details. We'll take a closer look at an actual security advisory when we learn how to apply patches manually to the operating system.
Starting with the InstallationLet's start with the most common deployment scenario, using FreeBSD 5.2.1 RELEASE as our reference platform. For this version, the CVS tag is 5_2_1 for the version shipped on CD and 5_2 for the security branch. (5_2 applies even to FreeBSD 5.2.1.) The administrator installs FreeBSD 5.2.1 RELEASE from CD on a new server. She installs the Developer distribution set so she has "Full sources, binaries and doc but no games." When installation is done, a check of uname output shows what the system looks like prior to any changes: freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386She does not need to modify the kernel and is running the GENERIC version shipped with the OS. She does not need any enhancements offered by the STABLE tree and decides to track the 5.2 security branch.
Binary OS and Userland Updates with FreeBSD UpdateAdministrators who begin with a RELEASE system, who do not make any changes to the FreeBSD GENERIC kernel, and who have not made any changes to the userland, have a strong case for using binary upgrades. Binary upgrades replace the files copied from the original RELEASE CD-ROM (for example) with upgraded versions patched to address security issues.Using Colin Percival's FreeBSD Update tool, our administrator can quickly bring the system fully up-to-date with respect to the 5.2 security branch. [6] Remember her system must meet be a stock RELEASE installation with no userland or kernel changes to take full advantage of FreeBSD Update's ability to address security concerns. The administrator installs and runs FreeBSD Update by retrieving the tool as a remote, precompiled package. (Building the tool from source through the ports system as another acceptable option, and is actually preferred from a security standpoint.) freebsd521:/root# pkg_add -vr freebsd-update looking up ftp.freebsd.org connecting to ftp.freebsd.org:21 setting passive mode opening data connection initiating transfer Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages- 5.2.1-release/Latest/freebsd-update.tbz...+CONTENTS ...edited... extract: Package name is freebsd-update-1.4 extract: CWD to /usr/local extract: /usr/local/man/man5/freebsd-update.conf.5.gz extract: /usr/local/man/man8/freebsd-update.8.gz extract: /usr/local/sbin/freebsd-update extract: /usr/local/sbin/freebsd-update-verify extract: /usr/local/etc/freebsd-update.conf.sample extract: /usr/local/share/doc/freebsd-update/LICENSE extract: /usr/local/share/doc/freebsd-update/README extract: /usr/local/share/doc/freebsd-update/VERSION extract: CWD to . Running mtree for freebsd-update-1.4.. mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null Attempting to record package into /var/db/pkg/freebsd-update-1.4.. Trying to record dependency on package 'bsdiff-4.1' with 'misc/bsdiff' origin. Package freebsd-update-1.4 registered in /var/db/pkg/freebsd-update-1.4Next she creates a needed directory and makes a copy of a default configuration file: freebsd521:/root# mkdir -p /usr/local/freebsd-update freebsd521:/root# cp /usr/local/etc/freebsd-update.conf.sample /usr/local/etc/freebsd-update.confFinally she is ready to retrieve and apply updates. Remember to run 'rehash' if you need to recompute the hash table for $PATH used by the /bin/csh shell: freebsd521:/root# freebsd-update fetch Fetching public key... Fetching updates signature... Fetching updates... Fetching hash list signature... Fetching hash list... Examining local system... Fetching updates... /boot/kernel/kernel... /boot/kernel/linux.ko... /lib/libcrypto.so.3... /usr/bin/cvs... /usr/bin/fetch... /usr/include/krb5-protos.h... /usr/include/netinet/ip6.h... /usr/include/netinet/tcp_var.h... /usr/include/openssl/opensslv.h... /usr/lib/libcrypto.a... /usr/lib/libcrypto_p.a... /usr/lib/libkrb5.a... /usr/lib/libkrb5.so.7... /usr/lib/libkrb5_p.a... /usr/lib/libssl.a... /usr/lib/libssl.so.3... /usr/lib/libssl_p.a... /usr/libexec/kdc... /usr/share/man/man8/kdc.8.gz... Updates fetchedWe see this process has downloaded a variety of files, including a new kernel (named "kernel"), a new kernel module (linux.ko), and a variety of binaries, libraries, and man pages. Next the administrator applies the patches: freebsd521:/root# freebsd-update install Backing up /boot/kernel/kernel... Installing new /boot/kernel/kernel... Backing up /boot/kernel/linux.ko... Installing new /boot/kernel/linux.ko... Backing up /lib/libcrypto.so.3... Installing new /lib/libcrypto.so.3... Backing up /usr/bin/cvs... Installing new /usr/bin/cvs... ...edited... Backing up /usr/share/man/man8/kdc.8.gz... Installing new /usr/share/man/man8/kdc.8.gz...When done, the administrator reboots the system. A reboot is needed because the kernel itself was updated. After reboot, observe the new uname output: freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-SECURITY FreeBSD 5.2.1-SECURITY #0: Tue Sep 28 17:27:41 GMT 2004 root@builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386Whereas the last uname output showed "5.2.1-RELEASE" as the version, with a kernel compilation date of "Mon Feb 23 20:45:55 GMT 2004", the security branch shows "5.2.1-SECURITY" and "Tue Sep 28 17:27:41 GMT 2004". You can verify that your FreeBSD system required no other binary upgrades by running FreeBSD Update again: freebsd521:/root# freebsd-update fetch Fetching updates signature... Fetching hash list signature... Examining local system... No updates availableSince no updates are available, the system is patched. FreeBSD Update is a simple yet powerful way to keep a FreeBSD machine aligned with the security branch. Its primary drawback is its inability to update a kernel customized by the system administrator. Since it's not possible for Colin to imagine all of the different kernel modifications administrators might make, he is restricted to building binary upgrades of the stock GENERIC kernel. While the GENERIC kernel is appropriate for many deployments, its lack of IPSec support, for example, might prompt an administrator to deviate from the GENERIC path. FreeBSD Update cannot handle changes to the userland that deviate from what was packaged with a RELEASE, either. If an administrator tinkers with a driver or tool, and that file subsequently requires a security fix, FreeBSD Update will not try to replace it be default. However, FreeBSD Update's author Colin Percival notes: "FreeBSD Update can be forced to download security fixes for files which have been locally modified by using the --branch option starting with version 1.5. The "branches" here are "nocrypto", "crypto", "krb4", and "krb5"; most users would be running a system with cryptography but without optional Kerberos support, so they would use "--branch crypto". Of course, this will obliterate any local changes they have made to the files being updated, but it's useful if you've recompiled the world without actually making any changes."
Applying Kernel Patches ManuallyFreeBSD Update might seem too simple for your tastes. Alternatively, you want the control of working with the source yourself or you might be running a custom kernel. Whenever you change the userland or kernel beyond what was shipped with a RELEASE, binary upgrades become problematic.This section demonstrates how to patch a FreeBSD 5.2.1 RELEASE system, showing commands and output. Administrators learn of security issues by reading advisories, so it is helpful to see what those bulletins contain. We start down the road of manual patching by looking at the first security advisory to affect FreeBSD 5.2.1 RELEASE, of which an excerpt is printed below:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-04:04.tcp Security Advisory
The FreeBSD Project
Topic: many out-of-sequence TCP packets denial-of-service
Category: core
Module: kernel
Announced: 2004-03-02
Revised: 2004-03-16
Credits: iDEFENSE, Alexander Cuttergo
Affects: All FreeBSD releases
Corrected: 2004-03-02 17:19:18 UTC (RELENG_4)
2004-03-16 13:47:33 UTC (RELENG_5_2, 5.2.1-RELEASE-p2)
2004-03-15 20:02:06 UTC (RELENG_5_1, 5.1-RELEASE-p15)
2004-03-02 17:26:33 UTC (RELENG_4_9, 4.9-RELEASE-p3)
2004-03-02 17:27:47 UTC (RELENG_4_8, 4.8-RELEASE-p16)
2004-03-17 10:50:45 UTC (RELENG_4_7, 4.7-RELEASE-p26)
CVE Name: CAN-2004-0171
FreeBSD only: NO
0. Revision History
v1.0 2004-03-02 Initial release.
v1.1 2004-03-17 Fix minor performance issue in 5.2.1 patch.
Corrections for RELENG_5_1 and RELENG_4_7 added.
Note Alexander Cuttergo as the discoverer of this issue.
I. Background
The Transmission Control Protocol (TCP) of the TCP/IP protocol suite
provides a connection-oriented, reliable, sequence-preserving data
stream service. When network packets making up a TCP stream (``TCP
segments'') are received out-of-sequence, they are maintained in a
reassembly queue by the destination system until they can be re-ordered
and re-assembled.
II. Problem Description
FreeBSD does not limit the number of TCP segments that may be held in a
reassembly queue.
III. Impact
A remote attacker may conduct a low-bandwidth denial-of-service attack
against a machine providing services based on TCP (there are many such
services, including HTTP, SMTP, and FTP). By sending many
out-of-sequence TCP segments, the attacker can cause the target machine
to consume all available memory buffers (``mbufs''), likely leading to
a system crash.
IV. Workaround
It may be possible to mitigate some denial-of-service attacks by
implementing timeouts at the application level.
V. Solution
Do one of the following:
1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_2,
RELENG_4_9, or RELENG_4_8 security branch dated after the correction
date.
OR
2) Patch your present system:
The following patch has been verified to apply to FreeBSD 4.x and 5.x
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 5.2]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc
...edited...
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
...edited...
RELENG_5_2
src/UPDATING 1.282.2.10
src/sys/conf/newvers.sh 1.56.2.9
src/sys/netinet/tcp_input.c 1.217.2.3
src/sys/netinet/tcp_subr.c 1.169.2.4
src/sys/netinet/tcp_var.h 1.93.2.2
...edited...
- -------------------------------------------------------------------------
VII. References
<URL:http://www.idefense.com/application/poi/display?id=78&type=vulnerabilities>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAWC4yFdaIBMps37IRAgulAJ93O5yH4Z49oTx4HEdRJK+6sLco2gCfYCEZ
NpPTCWlG1oyLjOL2y6zKBfs=
=Naox
-----END PGP SIGNATURE-----
Advisory FreeBSD-SA-04:04.tcp describes a potential denial of service condition in the FreeBSD kernel. The kernel handles reassembling TCP packets, so the kernel must be upgraded to fix this problem.
We see that the solution for this problem requires upgrading to the RELENG_5_2 branch dated after date of the files affected by the advisory, or applying a patch located at this link for FreeBSD 5.2: ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch Here we demonstrate how to apply a patch to the kernel, and then how to recompile the kernel. Where wget(1) is used, feel free to substitute fetch(1) if wget(1) is not installed on your system. First we install GNU Privacy Guard (gpg) so we can verify the authenticity of the patch, then obtain and import the key of the FreeBSD security officer: freebsd521:/root# pkg_add -vr gnupg ...edited... Package gnupg-1.2.3_4 registered in /var/db/pkg/gnupg-1.2.3_4 freebsd521:/root# rehash freebsd521:/root# gpg --version gpg (GnuPG) 1.2.3 Copyright (C) 2003 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256 Compression: Uncompressed, ZIP, ZLIB freebsd521:/root# wget ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc ...edited... freebsd521:/root# gpg --import public_key.asc gpg: /root/.gnupg: directory created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key CA6CDFB2: public key "FreeBSD Security Officer <security-officer@FreeBSD.org>" imported gpg: Total number processed: 1 gpg: imported: 1Alternatively, you can import the keys of all of the developers right from your hard drive: gpg --import /usr/share/doc/en_US.ISO8859-1/books/handbook/pgpkeys-developers.htmlSecond we download the patch and the GPG-signature, and then verify the signature: freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch Receiving tcp52.patch (6182 bytes): 100% 6182 bytes transferred in 0.1 seconds (49.28 kBps) freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc Receiving tcp52.patch.asc (186 bytes): 100% 186 bytes transferred in 0.0 seconds (23.98 kBps) freebsd521:/root# gpg --verify tcp52.patch.asc tcp52.patch gpg: Signature made Tue Mar 2 12:10:17 2004 EST using DSA key ID CA6CDFB2 gpg: Good signature from "FreeBSD Security Officer <security-officer@FreeBSD.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: C374 0FC5 69A6 FBB1 4AED B131 15D6 8804 CA6C DFB2GPG warns us that we have not taken any steps to trust the signature of the FreeBSD Security Officer. One of the ways to make this warning disappear would be to sign the key of the FreeBSD Security Officer ourselves. We might do that after confirming in person or on the telephone that the primary key fingerprint of the FreeBSD Security Officer's key is as stated in the output above. (Beyond this example, I will not show verifying future patches.) For now we assume that the tcp52.patch has not been tampered with and move on to applying it per the advisory's instructions: freebsd521:/usr/src# patch < /root/tcp52.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |? tcp_reass-5.2.1-20040301.patch |Index: tcp_input.c |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v |retrieving revision 1.217.2.1 |diff -u -p -r1.217.2.1 tcp_input.c |--- sys/netinet/tcp_input.c 9 Jan 2004 12:32:36 -0000 1.217.2.1 |+++ sys/netinet/tcp_input.c 1 Mar 2004 15:18:54 -0000 -------------------------- Patching file sys/netinet/tcp_input.c using Plan A... Hunk #1 succeeded at 57. Hunk #2 succeeded at 99. Hunk #3 succeeded at 134. Hunk #4 succeeded at 192. Hunk #5 succeeded at 215. Hunk #6 succeeded at 226. Hunk #7 succeeded at 276. Hunk #8 succeeded at 312. Hunk #9 succeeded at 347. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: tcp_subr.c |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v |retrieving revision 1.169.2.3 |diff -u -p -r1.169.2.3 tcp_subr.c |--- sys/netinet/tcp_subr.c 23 Feb 2004 15:32:55 -0000 1.169.2.3 |+++ sys/netinet/tcp_subr.c 1 Mar 2004 15:18:54 -0000 -------------------------- Patching file sys/netinet/tcp_subr.c using Plan A... Hunk #1 succeeded at 286. Hunk #2 succeeded at 709. Hunk #3 succeeded at 771. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: tcp_var.h |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v |retrieving revision 1.93.2.1 |diff -u -p -r1.93.2.1 tcp_var.h |--- sys/netinet/tcp_var.h 9 Jan 2004 12:32:36 -0000 1.93.2.1 |+++ sys/netinet/tcp_var.h 1 Mar 2004 15:18:55 -0000 -------------------------- Patching file sys/netinet/tcp_var.h using Plan A... Hunk #1 succeeded at 54. Hunk #2 succeeded at 513. doneNow that the patch is applied, we must rebuild our kernel. [8] Since we are going to be recompiling the kernel, we are free to make changes to its configuration. We copy the GENERIC kernel to a file named for our system (freebsd521). Readers familiar with FreeBSD conventions might recognize that kernel configuration files are normally named in uppercase, e.g., FREEBSD521. This difference does not affect the outcome, but readers are encouraged to name their kernel configuration file according to the uppercase convention: freebsd521:/usr/src# cd /usr/src/sys/i386/conf freebsd521:/usr/src/sys/i386/conf# cp GENERIC freebsd521Next we make a few changes to omit support for the Intel 486 and 586 class CPUs and change the kernel identifier to our hostname: # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.394.2.3 2004/01/26 19:42:11 nectar Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU #ident GENERIC ident freebsd521There are dozens of other changes that could be made, such as removing support for unnecessary hardware, or making optimizations. I recommend reviewing the Handbook or one of the excellent books on FreeBSD to learn more about kernel modifications. Finally we compile and install the new kernel: freebsd521:/usr/src# make buildkernel KERNCONF=freebsd521 -------------------------------------------------------------- >>> Kernel build for freebsd521 started on Sat Nov 27 19:45:44 EST 2004 -------------------------------------------------------------- ===> freebsd521 mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/i386/legacy/usr/sbin: /usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games: /usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr /src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/freebsd521 /usr/src/sys/i386/conf/freebsd521 Kernel build directory is /usr/obj/usr/src/sys/freebsd521 ...edited... -------------------------------------------------------------- >>> Kernel build for freebsd521 completed on Sat Nov 27 21:25:30 EST 2004 -------------------------------------------------------------- freebsd521:/usr/src# make installkernel KERNCONF=freebsd521 cd /usr/obj/usr/src/sys/freebsd521; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr /src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy /usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy /usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin: /usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy /usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr /bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install ...edited... ===> vesa install -o root -g wheel -m 555 vesa.ko /boot/kernel kldxref /boot/kernel freebsd521:/usr/src# shutdown -r nowAfter the reboot, the uname output is slightly different: freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Sat Nov 27 20:36:48 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386Whereas the original system's uname output showed the GENERIC kernel, this system displays a kernel called freebsd521. This example demonstrated how to patch and recompile the FreeBSD kernel. The main drawback for this sort of patching is the time required to recompile and install the kernel, as it can take a long time on older machines. It is possible to recompile the world and kernel on a fast machine, and then install both on a slower machine. I wrote a Blog entry demonstrating how to do this, titled "Building Kernel and World on One System, Installing on Another." [9]
Applying Userland Patches Manually, Part 1In the previous section we patched, recompiled, and reinstalled the FreeBSD kernel. Kernel vulnerabilities are less common that userland vulnerabilities. In this section we look at patching, recompiling, and reinstalling userland applications (also known as the "world"). [10] This approach was advocated in the second advisory to affect FreeBSD 5.2.1:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-04:05.openssl Security Advisory
The FreeBSD Project
Topic: Denial-of-service vulnerability in OpenSSL
Category: crypto
Module: openssl
Announced: 2004-03-17
Credits: OpenSSL Project <URL:http://www.openssl.org>
Codenomicon Ltd <URL:http://www.codenomicon.com>
Affects: All FreeBSD 4.x and 5.x releases
Corrected: 2004-03-17 12:23:51 UTC (RELENG_4, 4.9-STABLE)
2004-03-17 12:14:12 UTC (RELENG_5_2, 5.2.1-RELEASE-p3)
2004-03-17 12:14:56 UTC (RELENG_5_1, 5.1-RELEASE-p16)
2004-03-17 12:17:13 UTC (RELENG_4_9, 4.9-RELEASE-p4)
2004-03-17 12:18:23 UTC (RELENG_4_8, 4.8-RELEASE-p17)
CVE Name: CAN-2004-0079
FreeBSD only: NO
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/ >.
I. Background
FreeBSD includes software from the OpenSSL Project. The OpenSSL
Project is a collaborative effort to develop a robust, commercial-
grade, full-featured, and Open Source toolkit implementing the Secure
Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1)
protocols as well as a full-strength general purpose cryptography
library.
II. Problem Description
When processing an SSL/TLS ChangeCipherSpec message, OpenSSL may fail to
check that a new cipher has been previously negotiated. This may result
in a null pointer dereference.
III. Impact
A remote attacker could perform a specially crafted SSL/TLS handshake
with an application that utilizes OpenSSL, triggering the null pointer
dereference and causing the application to crash. Depending upon the
specifics of the application, this may result in an effective
denial-of-service.
IV. Workaround
No workaround is known.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_2,
RELENG_4_9, or RELENG_4_8 security branch dated after the correction
date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.8,
4.9, 5.1, and 5.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system as described in
<URL: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >.
Note that any statically linked applications that are not part of the
base system (i.e. from the Ports Collection or other 3rd-party sources)
must be recompiled.
All affected applications must be restarted for them to use the
corrected library. Though not required, rebooting may be the easiest
way to accomplish this.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
...edited...
RELENG_5_2
src/UPDATING 1.282.2.11
src/crypto/openssl/crypto/opensslv.h 1.1.1.14.2.1
src/crypto/openssl/ssl/s3_pkt.c 1.1.1.8.4.1
src/sys/conf/newvers.sh 1.56.2.10
...edited...
- -------------------------------------------------------------------------
VII. References
<URL: http://www.openssl.org/news/secadv_20040317.txt >
<URL: http://cvs.openssl.org/chngview?cn=12033 >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAWH8nFdaIBMps37IRAgsZAKCPXaoTb16c8JGJL+Uz7eOX8/864ACbB059
AIfN8fbeiGJ3fdG0pKAMwMw=
=2f24
-----END PGP SIGNATURE-----
For this example, we download the patch, apply it, and then recompile and reinstall the world. To accomplish this process, you must have a complete set of system source code. Without it, FreeBSD cannot recompile the userland applications. Because our system administrator installed the "Developer" distribution set, she has "Full sources, binaries and doc but no games."
If you do not have the required distribution set, you can either install them via /stand/sysinstall (now /usr/sbin/sysinstall in newer distributions) or check them out using CVS. I recommend checking them out via CVS as described in the section "CVSup to 5_2 Security Branch" below. freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch ...edited... freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch.asc freebsd521:/root# cd /usr/src freebsd521:/usr/src# patch < /root/openssl.patch Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Index: crypto/openssl/ssl/s3_pkt.c |=================================================================== |RCS file: /home/ncvs/src/crypto/openssl/ssl/s3_pkt.c,v |retrieving revision 1.1.1.8 |diff -c -r1.1.1.8 s3_pkt.c |*** crypto/openssl/ssl/s3_pkt.c 19 Feb 2003 23:17:05 -0000 1.1.1.8 |--- crypto/openssl/ssl/s3_pkt.c 16 Mar 2004 13:18:28 -0000 -------------------------- Patching file crypto/openssl/ssl/s3_pkt.c using Plan A... Hunk #1 succeeded at 1085. done freebsd521:/usr/src# make buildworld -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/i386 mkdir -p /usr/obj/usr/src/i386/legacy/usr/bin mkdir -p /usr/obj/usr/src/i386/legacy/usr/games mkdir -p /usr/obj/usr/src/i386/legacy/usr/include/sys ...edited... ===> etc ===> etc/sendmail rm -f freebsd.cf m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.mc > freebsd.cf chmod 444 freebsd.cf rm -f freebsd.submit.cf m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.submit.mc > freebsd.submit.cf chmod 444 freebsd.submit.cfBefore we take the next step, we notice that advisory FreeBSD-SA-04:06.ipv6 warns against local attackers potentially reading kernel memory or causing kernel panics. For now we opt to implement the recommended workaround:
1) Disable IPv6 entirely by following these steps:
- Remove or comment out any lines mentioning `INET6' from your
kernel configuration file, and recompile your kernel as described
in <URL:http://www.freebsd.org/handbook/kernelconfig.html >.
- Reboot your system.
We disable IPv6 by commenting out the following line in our kernel config file called "freebsd521" (a modified copy of GENERIC) as shown:
#options INET6 #IPv6 communications protocolsNote that we must be aware of the ramifications of implementing this workaround. For example, certain kernel modules are compiled with support for IPv6 and may not function properly if the kernel itself is compiled without IPv6 support. Continuing with our process, we recompile and rebuild the kernel as we did for the TCP kernel advisory. freebsd521:/usr/src# make buildkernel KERNCONF=freebsd521 ...edited... freebsd521:/usr/src# make installkernel KERNCONF=freebsd521 ...edited...At this point official FreeBSD documentation recommends rebooting into single user mode. Readers are encouraged to do so, if they have local access to the system being upgraded. I have not had problems performing remote upgrades over SSH connections. For specifics on how to handle questions posed by mergemaster, I recommend referencing the FreeBSD Handbook. In brief, you accept changes to files with the 'i' command and reject (or "delete" them) with the 'd' command. You merge them with 'm'. For example, I delete the files proposed to replace my own /etc/hosts file, but I install the new /etc/motd file. freebsd521:/usr/src# mergemaster -p ...edited... freebsd521:/usr/src# make installworld ...edited... ===> etc ===> etc/sendmail -------------------------------------------------------------- >>> Rebuilding man page indices -------------------------------------------------------------- cd /usr/src/share/man; make makedb makewhatis /usr/share/man makewhatis /usr/share/openssl/man rm -rf /tmp/install.byiy1xGn freebsd521:/usr/src# mergemaster ...edited... freebsd521:/usr/src# shutdown -r nowWhen the system reboots, the uname output will be different: freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #1: Sun Nov 28 14:46:01 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386The previous uname output listed "FreeBSD 5.2.1-RELEASE #0" as the version number. Here the 0 has increased to 1 to show that the kernel has been recompiled again.
Applying Userland Patches Manually, Part 2 Sometimes the FreeBSD security team doesn't advocate recompiling and reinstalling the entire userland. (The normal buildworld/installworld process is still completely acceptable, if you choose to do that.) This was the case with FreeBSD-SA-04:07.cvs, which affected the CVS binary. Here are the correction details alone:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-04:07.cvs Security Advisory
The FreeBSD Project
...edited...
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.8,
4.9, 5.1, and 5.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:07/cvs.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:07/cvs.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/gnu/usr.bin/cvs
# make obj && make depend && make && make install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
...edited...
RELENG_5_2
src/UPDATING 1.282.2.13
src/sys/conf/newvers.sh 1.56.2.12
src/contrib/cvs/src/client.c 1.10.4.1
src/contrib/cvs/src/modules.c 1.1.1.8.6.2
...edited...
- -------------------------------------------------------------------------
...truncated...
We download and apply the patch per the advisory:
freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:07/cvs.patch Receiving cvs.patch (1913 bytes): 100% 1913 bytes transferred in 0.0 seconds (386.53 kBps) freebsd521:/root# cd /usr/src freebsd521:/usr/src# patch < /root/cvs.patch Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Index: contrib/cvs/src/client.c |=================================================================== |RCS file: /home/ncvs/src/contrib/cvs/src/client.c,v |retrieving revision 1.10 |diff -c -r1.10 client.c |*** contrib/cvs/src/client.c 21 Jan 2003 22:01:38 -0000 1.10 |--- contrib/cvs/src/client.c 14 Apr 2004 15:51:51 -0000 -------------------------- Patching file contrib/cvs/src/client.c using Plan A... Hunk #1 succeeded at 1054. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Index: contrib/cvs/src/modules.c |=================================================================== |RCS file: /home/ncvs/src/contrib/cvs/src/modules.c,v |retrieving revision 1.1.1.9 |diff -c -r1.1.1.9 modules.c |*** contrib/cvs/src/modules.c 21 Jan 2004 16:27:56 -0000 1.1.1.9 |--- contrib/cvs/src/modules.c 14 Apr 2004 15:54:51 -0000 -------------------------- Patching file contrib/cvs/src/modules.c using Plan A... Hunk #1 succeeded at 170. doneNow we recompile and reinstall the affected components: freebsd521:/usr/src# cd /usr/src/gnu/usr.bin/cvs freebsd521:/usr/src/gnu/usr.bin/cvs# make obj ===> lib ===> libdiff ===> cvs ===> contrib ===> cvsbug ===> doc freebsd521:/usr/src/gnu/usr.bin/cvs# make depend ===> lib ===> libdiff ===> cvs rm -f .depend mkdep -f .depend -a -I/usr/src/gnu/usr.bin/cvs/cvs -I../lib -DHAVE_CONFIG_H ...edited... ===> contrib ===> cvsbug ===> doc freebsd521:/usr/src/gnu/usr.bin/cvs# make ===> lib ===> libdiff ===> cvs cc -O -pipe -mcpu=pentiumpro -I/usr/src/gnu/usr.bin/cvs/cvs -I../lib -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -I. -DHAVE_GSSAPI -DHAVE_GSSAPI_H -DENCRYPTION -c /usr/src/contrib/cvs/src/client.c ...edited... ===> contrib ===> cvsbug ===> doc freebsd521:/usr/src/gnu/usr.bin/cvs# make install ===> lib ===> libdiff ===> cvs install -s -o root -g wheel -m 555 cvs /usr/bin install -o root -g wheel -m 444 cvs.1.gz /usr/share/man/man1 ...edited... install-info --quiet --defsection="Programming & development tools." --defentry="* CVS-CLIENT: (cvsclient). CVS client/server Reference Manual." cvsclient.info /usr/share/info/dir install -o root -g wheel -m 444 cvs.info.gz cvsclient.info.gz /usr/share/infoWe have successfully patched the CVS tool; nothing else needs to be done in this case.
CVSup to 5_2 Security BranchAt this point we've manually patched, recompiled, and reinstalled the FreeBSD kernel, userland (world), and a set of userland binaries on FreeBSD 5.2.1. From this point forward we decide that tracking the FreeBSD 5.2 security release would be easier than the piecemeal patching approach followed thus far.To track the 5.2 security branch, we must install CVSup. [7] CVSup will allow us to check out a specified version of FreeBSD from CVS, after which we must recompile and reinstall the world and kernel. Begin by installing the precompiled cvsup-without-gui package: pkg_add -vr cvsup-without-guiWe create a security-supfile in /usr/local/etc/ containing the following entries. The security-supfile tells CVSup the version of the files to check out from the FreeBSD CVS repository. We choose cvsup3.freebsd.org, although you are encouraged to choose a CVSup server closest to the location of your system. Notice we specifiy RELENG_5_2 as the CVS tag. RELENG_5_2 is the security branch for FreeBSD 5.2.1. *default host=cvsup3.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_5_2 *default delete use-rel-suffix *default compress src-allWith this configuration file created, we are ready to start CVSup. The -g switch disables the GUI and the -L 2 switch increases the verbosity of the output. freebsd521:/root# cvsup -g -L 2 /usr/local/etc/security-supfile Parsing supfile "/usr/local/etc/security-supfile" Connecting to cvsup3.FreeBSD.org Connected to cvsup3.FreeBSD.org Server software version: SNAP_16_1e Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Checkout src/UPDATING Checkout src/contrib/cvs/lib/xsize.h Checkout src/contrib/cvs/src/client.c Edit src/contrib/cvs/src/commit.c Add delta 1.13.4.1 2004.09.19.22.37.10 nectar Edit src/contrib/cvs/src/cvs.h Add delta 1.17.4.1 2004.09.19.22.37.10 nectar Edit src/contrib/cvs/src/filesubr.c Add delta 1.10.6.1 2004.09.19.22.37.10 nectar ...edited... Edit src/usr.bin/fetch/fetch.c Add delta 1.62.4.1 2004.11.18.12.04.29 cperciva SetAttrs src/usr.bin/lex/mkskel.sh,v SetAttrs src/usr.sbin/pkg_install/tkpkg,v Shutting down connection to server Finished successfullyIf you are sitting behind a firewall that doesn't allow outbound access to port 5999 TCP on the CVSup server, you can try creating a tunnel with OpenSSH. For example, if you have outbound SSH access to system 'bouncehost', you can create a tunnel like this: freebsd521:/root# ssh -v -L 5999:cvsup3.freebsd.org:5999 user@bouncehostWhen you run cvsup, invoke it this way: freebsd521:/root# cvsup -g -L 2 -h localhost /usr/local/etc/security-supfileNow that CVSup has checked out all of the changes, we proceed with recompiling and reinstalling the world and kernel. This is the same process we followed for the OpenSSL vulnerability. The commands are: cd /usr/src make buildworld make buildkernel KERNCONF=freebsd521 make installkernel KERNCONF=freebsd521 mergemaster -p make installworld mergemaster shutdown -r nowUpon reboot we look at the uname output: freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE-p12 FreeBSD 5.2.1-RELEASE-p12 #2: Mon Nov 29 02:39:09 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386Notice two important aspects of this uname output. First, the FreeBSD version is now "FreeBSD 5.2.1-RELEASE-p12". The p12 indicates a sort a patch level. Since FreeBSD 5.2.1 was released, 11 advisories have been published affecting FreeBSD 5.2.1. The first advisory (FreeBSD-SA-04:04.tcp) was corrected by 5.2.1-RELEASE-p2. The tenth advisory to affected 5.2.1, FreeBSD-SA-04:16.fetch, is corrected by 5.2.1-RELEASE-p12. This is the version of the security branch we are now running. The "#2" indicates the "freebsd521" kernel has again been recompiled and reinstalled. Previously this number was "#1".
Beyond the Security BranchLet's say you wanted to upgrade from the FreeBSD 5.2 security branch to FreeBSD 5.3 RELEASE. Create a new "supfile" (perhaps call it 5.3_REL-supfile) with these contents:*default host=cvsup3.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_5_3_0_RELEASE *default delete use-rel-suffix *default compress src-allNotice that the only difference between this supfile and the previous is the CVS tag. Then follow the commands in the previous section, beginning by CVSup'ing to the new version: cvsup -g -L 2 /usr/local/etc/5.3_REL-supfileContinue with 'cd /usr/src', 'make buildworld', and so on. When done you will be running FreeBSD 5.3 RELEASE. If you wanted to track the FreeBSD 5.3 security branch, change the CVS tag from "RELENG_5_3_0_RELEASE" to "RELENG_5_3". If one wanted to upgrade from any version of FreeBSD 5.2, it would make sense to upgrade to at least the security branch of FreeBSD 5.3. Why bother going though the process to end up running the same unpatched version found on the FreeBSD 5.3 RELEASE CD-ROM?
STABLE: The End of the LineThe end of the line in the FreeBSD 5.x tree is 5-STABLE. The STABLE tree incorporates not only bug fixes and security patches, but upgrades that are Merged From CURRENT (aka "MFC'd"). STABLE is a constantly moving target, marked only by the date and time that an administrator uses CVSup to sync with the STABLE tree. For this reason, security advisories, such as FreeBSD-SA-04:16.fetch, will list the date and time at which a STABLE branch incorporates a security fix:Corrected: 2004-11-18 12:02:13 UTC (RELENG_5, 5.3-STABLE)If your STABLE is older than the date specified, your system is vulnerable. Compare that method of gauging a system's exposure to the "patch level" of running the security branch. From the same advisory:
2004-11-18 12:03:05 UTC (RELENG_5_3, 5.3-RELEASE-p1)
2004-11-18 12:04:29 UTC (RELENG_5_2, 5.2.1-RELEASE-p12)
Here we also have a timestamp, but it's easier to see that 5.3-RELEASE-p1 and 5.2.1-RELEASE-p12 are patched for the "fetch" vulnerability.
For demonstration purposes, we will upgrade our FreeBSD 5.2.1-RELEASE-p12 system to STABLE by creating a stable-supfile with these contents: *default host=cvsup3.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_5 *default delete use-rel-suffix *default compress src-allNext we follow the commands introduced in the "CVSup to 5_2 Security Branch" section to upgrade to STABLE. Begin with: cvsup -g -L 2 /usr/local/etc/stable-supfileContinue with 'cd /usr/src', 'make buildworld', and so on. When done you will be running FreeBSD 5-STABLE. When done our uname output appears as follows: freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.3-STABLE FreeBSD 5.3-STABLE #3: Tue Nov 30 20:16:13 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386Note that the version is "FreeBSD 5.3-STABLE" and the "#3" indicates that the "freebsd521" kernel has been recompiled again. For future security advisories, we check to see if the "corrected by" date is earlier than the "Tue Nov 30 20:16:13 EST 2004" date in our uname output.
The "Next" STABLEThe day after I completed the upgrade to the STABLE with timestamp "Tue Nov 30 20:16:13 EST 2004", the FreeBSD Security Team released a new advisory (FreeBSD-SA-04:17.procfs). That advisory lists the versions of FreeBSD which have the latest problem corrected:
Corrected: 2004-12-01 21:33:35 UTC (RELENG_5, 5.3-STABLE)
2004-12-01 21:34:23 UTC (RELENG_5_3, 5.3-RELEASE-p2)
2004-12-01 21:34:43 UTC (RELENG_5_2, 5.2.1-RELEASE-p13)
...truncated...
Since the timestamp for STABLE is "2004-12-01 21:33:35 UTC", and that is later than the STABLE timestamp on my demo system, I must correct the problem as described in the new advisory.
I can also check the advisory for the files which need to be corrected. They are listed for the STABLE tree in the advisory as follows: RELENG_5 src/sys/compat/linprocfs/linprocfs.c 1.84.2.1 src/sys/fs/procfs/procfs_status.c 1.52.2.1By drilling down through the CVSWeb.freebsd.org interface, I can review the exact changes needed to fix each file: The ability to see exactly what a patch corrects, by looking at actual source code, is incredibly powerful and educational. By reviewing the code you have a sense of what the developers did to address the issue and you can judge if their fix is appropriate.
ConclusionI hope this article has helped you understand the different ways to keep a FreeBSD system up-to-date with security advisories. It is by no means comprehensive, but by following it you hopefully can judge the different ways to keep your system in sync with the latest security patches and fixes for FreeBSD.
AcknowledgementsI'd like to thank Michael Lucas, Colin Percival, Dru Lavigne, Maarten Midden, Terry Erickson, Marius Nunnerich, and Julien Gabel for their timely and helpful feedback on this article.
References
|