A FreeBSD Christmas Advisory

25 December, 2011 12:26 CST6CDT

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:

Hi all,

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.

--
Colin Percival

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

III. Impact

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

Software  Article & Comments

Add a Comment

<p>, <br>, <em>, and <a> OK
Verification (Required) authimage
Your comment will appear once it is approved and
your e-mail address will NOT be shared

Main Entry:   spew   Pronunciation:   \ˈspyü\
Function: 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

intransitive verb
  1. VOMIT
  2. to come forth in a flood or gush
  3. to ooze out as if under pressure : EXUDE
transitive verb
  1. VOMIT
  2. to send or cast forth with vigor or violence or in great quantity <a volcano spewing out ash> —often used with out —spew·er noun
Land where drunk cows swim and home to my daily hand