BSD Links · New Links · Advocacy · Drivers · Events · Flavours · FAQs · Guides · Programming · Security · Software · User Groups

This is the BSDA Study Guide Book written via a wiki collaboration. This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Follow_the_instructions_in_a_security_advisory_to_apply_a_security_patch.html. Follow the instructions in a security advisory to apply a security patch Concept Be aware that each BSD project maintains security advisories which are available both on the Internet and via mailing lists. Be able to follow the instructions in an advisory when asked to do so by a supervisor. Introduction On occasion, experienced programmers and security researchers find "bugs" in every operating system. Some errors may allow unauthorized use of, or control over, system resources and are therefore classed as "security issues". Organizations such as SANS and MITRE publish advisories regarding these "security issues" for many operating systems. As responsible "citizens" of the computing world, the BSD Projects maintain their own security officers and/or teams that work with other organizations to provide information about and security "fixes" for issues discovered in their software. A BSD system administrator should habitually check for security advisories issued by their Project. While you could check at MITRE or SANS, it is best to get your information directly from the source --- your own Project's security team or officer (after all, they are the ones who are supplying the information to others, anyway!) Finding Information on Security Advisories The BSD Projects are excellent at fixing security issues quickly. All Projects maintain security mailing lists and post security advisories on their websites. To read more about each Project's security efforts, see: FreeBSD: http://www.freebsd.org/security NetBSD: http://www.netbsd.org/security OpenBSD: http://www.openbsd.org/security.html To see which mailing lists are available, visit the following: FreeBSD: http://lists.freebsd.org/mailman/listinfo NetBSD: http://www.netbsd.org/MailingLists/ OpenBSD: http://www.openbsd.org/mail.html It's a pretty safe bet that each Project's "announce" list will send you mail in the event of a security advisory; there may be a better option, though. Check your Project's site for more details. Sample Security Advisories http://security.freebsd.org/advisories/FreeBSD-SA-07:01.jail.asc http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2006-027.txt.asc http://www.openbsd.org/errata.html#agp Dealing with Security Advisories A security advisory usually contains detailed, concise instructions on how to rectify the issue. Generally there are three options: Update the operating system to a corrected version/date; Patch the affected part(s) of the OS's source, then rebuild and reinstall the affected files; "Work around" the issue by disabling the affected service or configuration that allows the exploit. Each of these "options" is discussed below. Note that with some Projects, advances are being made that will allow you to securely download corrected binaries (if so, this would be considered a "fourth option"; it should be mentioned in the advisory text, if such an options exists). If this statement seems confusing, go back and read Understand the difference between a pre-compiled binary and compiling from source. Updating the operating system In almost every case, the Project's programmers will have corrected the security fault at the time the advisory is released, so upgrading to the latest version or "updated branch" of your operating system (if that is allowed by the situation) will "close" the security "hole". See the section Recognize which commands are available for upgrading the operating system for more details on upgrading. Patch the Affected Parts of the Operating System (Note: Now would be a great time to go back and read Understand the difference between a pre-compiled binary and compiling from source ... if you skipped that part by mistake). Along with the Security Advisory, your Project will likely have provided a software "patch" for the source code files involved in the issue. Following the instructions in the advisory, you can download the patch, verify its authenticity, and use your system's build tools (including patch(1), make(1), and others) to rebuild and reinstall the affected parts of the operating system. Note that if the issue involves the OS's "kernel", you may need to rebuild and reinstall the kernel and reboot. What's a 'patch', anyway? A patch is generally a small text file (generated by diff(1)) which contains only the "changes" made between two versions of a source code file(s) - the "previous version" (which contains code in which the "issue" was found) and the "corrected version" (in which the programmer(s) have "fixed" the "issue"). On systems that contain the source code for the affected software (the operating system, or the third-party utilities/packages/ports, etc.), you can use patch to update the affected source files to the "corrected version". At this point, depending on your BSD flavor, you would use tools (the same or similar to those used in updating the operating system) to create and install new binaries on the affected system. See the "Examples" section below for more details. "Work-Around" the Issue In some cases, a "work-around" may solve the problem, but generally this involves a "trade-off": you can't use feature "X" if you've disabled it due to a security issue. You may need to consult a senior systems administrator to determine whether a "workaround" would be appropriate for the system(s) you are responsible for. One thing is certain: in the rare case were a security issue is known to be "exploitable" and "in the wild", and a fix (such as a kernel compile or rebuild of the OS) may be an hour (or a half-day) in coming, it might be wise to "workaround" the issue to avoid a security breach on the system. However, you will notice I said, "in the rare case".... Most generally, the issues are found and fixed before exploits are available "in the wild". Once your new kernel or OS binaries are up and running, the affected subsystem(s) should be "re-enabled". Examples Here are excerpts from a FreeBSD Security Advisory: FreeBSD-SA-06:25.kmem Security Advisory The FreeBSD Project Topic: Kernel memory disclosure in firewire(4) Category: core Module: sys_dev Announced: 2006-12-06 Credits: Rodrigo Rubira Branco Affects: All FreeBSD releases. Corrected: 2006-12-06 09:13:51 UTC (RELENG_6, 6.2-STABLE) 2006-12-06 09:14:23 UTC (RELENG_6_2, 6.2-RC2) 2006-12-06 09:14:59 UTC (RELENG_6_1, 6.1-RELEASE-p11) Hopefully this is self-explanatory; generally the advisory is signed with the security officer's PGP key (not shown here) and includes some data that would allow you to quickly determine if your system(s) might be affected. Since this issue is a "core" issue that affects "all" releases, probably your FreeBSD system needs some attention. In this particular advisory, the text following the quote above lets us know that the problem is with the firewire(4) driver, the problem is that a signed integer was used by the programmer when an unsigned integer was needed, and that the issue centers on the possibility that a member of the "operator" group might be able to read kernel memory (which could contain sensitive information). If this was a real shrewd "operator" (pun intended), it might be possible to gain elevated privileges. Let's read on: IV. Workaround No workaround is available, but systems without IEEE 1394 ("FireWire") interfaces are not vulnerable. (Note that systems with IEEE 1394 interfaces are affected regardless of whether any devices are attached.) Note also that FreeBSD does not have any non-root users in the "operator" group by default; systems on which no users have been added to this group are therefore also not vulnerable. So, if the system has a firewire interface (some might breathe a sigh of relief here) and real users in the "operator" group, we must either update the entire system or patch the firewire driver (which is built into the kernel). We'll skip down to the nitty gritty: 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.11, 5.5, 6.0, and 6.1 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-06:25/kmem.patch # fetch http://security.FreeBSD.org/patches/SA-06:25/kmem.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in http://www.FreeBSD.org/handbook/kernelconfig.html and reboot the system. Practice Exercises More information patch(1), make(1), and fetch(1), ftp(1) and build.sh