|Front | Info | Lists | Newsfeeds | Study Guide | What is BSD?|
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
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:
To see which mailing lists are available, visit the following:
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
Dealing with Security Advisories
A security advisory usually contains detailed, concise instructions on how to rectify the issue. Generally there are three options:
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
What's a 'patch', anyway?
A patch is generally a small text file (generated by
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".
Here are excerpts from a FreeBSD Security Advisory:
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
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: