|Navigate Spew||Show Archives|
|Day to Day (234)||[RSS]|
|Squirrel Thursday (61)||[RSS]|
My education is in Computer Network Technologies. I use my free thought, when any thoughts are present, to write and produce content in a wide spectrum format flow. One day I may explain a method for accomplishing a task on a BSD operating system, or spewing about my latest Sandalwood acquisition, and other times I will keep my thoughts I put to the screen more personal and opinionated with my current gush of text in relation to my tempered mood.
BLOGS & Friends Pages
Nothing To Do With Arbroath
Nature's Gift Blog
Team FreeBSD Home
Team FreeBSD Contributors Page
Team FreeBSD Statistics
My Cache Stats
Links Visited Daily
Hack a Day
My Content and Media
Freshly Published News
My BOINC Statistics
Geeky, Funny & Strange
On December 23rd, 2011 FreeBSD administrators were blessed with 5 high severity security advisories. With some humor of a very unusual increase in fear on a single day, 5 security advisories total, the FreeBSD foundation sent out a follow-up after the advisories posted:
No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories.
The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories.
Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time.
While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some "symbols" (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong.
The first security advisory is a remote denial of service in the Bind DNS server affecting all maintained versions of FreeBSD. If Bind were able to cache an invalid DNS record, a DOS is possible if a local user could be tricked into querying the record in an inappropriate way through browsing an external web page in which a resource for the domain is needed, for example, or by self purpose. If Bind is an open DNS resolver, any external specially crafted query would also blow Bind 9 up. Authoritative only Bind 9 DNS servers do not 'seem' to be affected. A freebsd-update or a ports update to bind96-22.214.171.124.ESV.R5.1 should mitigate the security vulnerability.
Second security advisory (affecting all maintained versions of FreeBSD): if ftpd uses a chroot environment and nsdispatch. nsdispatch has the ability to reload its configuration on demand, and nsdispatch has no ability to notify itself if it is running in a chrooted environment allowing an ftpd user to gain elevated privileges, being that nsdispatch does not know the paths where configuration files and libraries are untrustworthy. Elevated ("root") privileges is possible.
The workaround is a mess as it adds a new API, __FreeBSD_libc_enter_restricted_mode() to the C library (libc). A freebsd-update should scare you sufficiently.
The third security advisory is telnetd (affecting all maintained versions of FreeBSD), not kidding:
II. Problem Description
When an encryption key is supplied via the TELNET protocol, its length is not validated before the key is copied into a fixed-size buffer.
An attacker who can connect to the telnetd daemon can execute arbitrary code with the privileges of the daemon (which is usually the "root" superuser).
On to the fourth security advisory (affecting all maintained versions of FreeBSD): if your SSH server (secure shell server) uses the pam_ssh authentication module, non encrypted SSH private keys, SSH inappropriately grants user access. "By default, the pam_ssh module rejects SSH private keys with no pass-phrase. A "nullok" option exists to allow these keys." The SSH PAM module is not enabled in default FreeBSD installations and SSH is not affected unless PAM authentication is explicitly enabled.
Holiday cheer security advisory number 5: pam_start() does not validate service names (affecting all maintained versions of FreeBSD) - users are able to define PAM policies with a path relative to /etc/pam.d or /usr/local/etc/pam.d, allowing the user define out of scope policies and execute their own modules. "If an application that runs with root privileges allows the user to specify the name of the PAM policy to load, users who are permitted to run that application will be able to execute arbitrary code with root privileges."
Main Entry: SPEW Pronunciation: \ˈspyü\intransitive verb
Etymology: Middle English, from Old English spīwan; akin to Old High German spIwan to spit, Latin spuere, Greek ptyein First Known Use: before 12th century
- to come forth in a flood or gush
- to ooze out as if under pressure : EXUDE