Apple released its 2006-001 security update last week, and we covered it briefly as it was released. However, we didn't exactly explain the patches in much detail. Apple's advisories only include a one or two sentence summary of each patch, which is insufficient to judge the severity of each patch. Potential impacts, mitigating factors and details are not discussed. In particular if you consider deploying OS X systems in larger installations, you should carefully study past advisories to decide if the detail provided will suffice to make intelligent patching decisions. For a home user, enabling automatic patching and follow a "patch and pray" approach is probably the best solution.

For Apple's version, see the "Security Update 2006-001"

apache_mod_php patch

This patch will move php to version 4.4.1. Sadly, php 4.4.2 is the most recent version of php as of this writing. The most important fixes implemented by version 4.4.1 are related to file upload handling and safe_mode issues. The impact of these vulnerability is severe for shared hosting environments. However, if you rely on protections provided by safe_mode for your own code, this upgrade is critical. You may want to consider compiling mod_php yourself using the sources found at php.net. this requires some experience in configuring and compiling a complex package like php and any custom php compile should be carefully tested before using it in a production environment.

Of course, the easiest way to mitigate this vulnerability is to disable Apache. Apache is not enabled by default. Even if you use Apache (and php) for development on your OS X desktop, you can limit it to listen on 127.0.0.1 only, or you may firewall the port.

This patch is in particular critical, as the vulnerability is known for a few months now. It has been patched in php since Oct. 31st 2005.

automount

"automount" is used to automatically mount local and remote file systems. The vulnerability is triggered if a remote file server uses a reserved name. Unfortunately, there is no third party advisory to provide more details. For example, it would be nice to know what configuration will allow such a file system to be mounted automatically. The advisory is mute to this point, but states that arbitrary code execution is possible. The advisory fails to note that automount is running as root and is missing any other mitigating configuration (e.g. chroot environment) which would limit the impact of an exploit.

BOM

BOM, a framework used to unpack files, the advisory fails to note which files are unpacked by BOM (btw: BOM appears to be shorthand for "Bill of Materials"). BOM will not check path names of unpacked files carefully enough, allowing malicious archives to write files to arbitrary locations accessible to the user.
Its a bit hard to tell how severe this is. It looks like this requires downloading a malicious archive, and expanding it. iDefense is providing more details. It advises to disable "open safe file types" in Safari to mitigate this issue. Important information that should have been included in Apple's advisory. 

Directory Services (passwd)

The title may be a bit odd, given that this is a vulnerability in the 'passwd' command. Apple suggests a temporary file vulnerability. These issues are common and usually refer to temporary files which are created by root, but not secured against overwriting. An attacker with access to the system could overwrite the file, and use it to executed arbitrary commands. A complete discussion of this issue can be found at iDefense and it provides for important details. The OS X passwd command allows the user to specify a password database name. This database name is not checked careful enough. As a result (remember: passwd runs as root) the user will be able to create arbitrary files. A second vulnerability exists in that "passwd" creates temporary files with predictable file names, allowing users to mount "symlink attacks".

iDefense also provides a simple workaround: Remove the "suid" bit from "/usr/sbin/passwd". This will prevent regular users from using "passwd" to elevate privileges. However, it will also prevent them from changing their password. Likely a sensible workaround while the patch is validated. You may want to use this opportunity to remove the suid bit from other binaries if you can do so.

File Vault

The 'filevault' encrypts a users home directory. This is a valuable feature in particular for notebooks and other physically vulnerable systems. As most file encryption schemes, it provides little additional protections for servers/remote exploits if the encrypted disks is mounted at all times. This vulnerability only exposes the protected files while the encrypted image is created. Apple does not detail the vulnerability. Later in the "security improvement" sections, Apple also refers to stricter permissions on the encrypted disk image.

The impact is likely minimal, as the exposure window is limited. However, hard to tell without more details.

IPSEC

This patch fixes a denial of service (DoS) condition that could be used to disconnect a VPN tunnel. Could be bad if this is a business critical tunnel (e.g. to a remote database?). Based on the credits, this looks like fallout from a test suite developed last year. While this is not a critical remote code execution vulnerability, it is nice that Apple is getting around to fix it.

Libsystem

Libsystem is the central systems library in OS X. It includes input/output functions, math libraries and other fundamental functions. Each OS X executable will use Libsystem. A vulnerability in this fundamental library is very critical as there may be numerous execution paths to trigger it. A full advisory can be found at the SureSec website.

There is no good workaround. This vulnerability could be used to escalate local privileges.

Mail

Mail suffers from the same 'safe file' issue as Safari. A file can be disguised as safe (e.g. as an image or a movie). This can be used to trick the user to click on the "image" to view it. As the user clicks on the file, it is executed without further warning. This issue is more of a problem in Safari (see below) and has been known for a couple weeks now.

Perl

Perl can be asked to drop "root" privileges and to continue to run as a regular user, after it performed a function that requires it to run as root (e.g. if may need to open a listening socket at a port < 1024). In order to achieve this, the perl command "$< = $UID" is used, where $UID is the numeric user id of the less privileged user. This problem has been known publicly until December 2005.

There is no good workaround. But again, if you don't have to run as root don't do it. However, dropping privileges after an initialization phase is typically the right way to avoid running as root.

rsync

rsync can be used to synchronize files with remote systems. It is a very efficient method to keep remote systems in sync with each other. The vulnerability appears to allow arbitrary code execution.
As a work around, and as a matter of best practice, access to rsync servers should be restricted. It is highly recommended to use rsync in conjunction with ssh.

Safari (multiple)

Before going into the detailed bugs: The #1 issue here is the "Launch Services" bug. This is a classic case where a secure-by-default configuration would reduce exposure.  Other browsers exist for OS X (Opera, Firefox). It is not clear which one should be recommended for OS X users. Either way, you may want to review your configuration.

Heap Overflow in WebKit

WebKit is the basic parsing/http client library used by Safari. Apple credits Suresec with the discovery of this vulnerability, but I am not able to find an advisory at the Suresec site. According to Apple, this vulnerability exposes the user to arbitrary code execution just by browsing to a malicious web site.

Javascript Stack Overflow

Malicious javascript could cause arbitrary code execution. Yet another vulnerability of the "browse here and die" kind.

Launch Services

This is the "open safe files after downloading" bug discussed over the last couple of weeks. In particular given the fact that this bug is trivial to exploit, patching is a must. On the other hand: I don't see a good reason to keep this option enabled even after you apply this patch. This vulnerability requires no user interaction aside from browsing to a malicious page. As other web based exploits, it could be embedded in bulletin boards, banner ads, and other content.

Syndication

Don't we all love RSS feeds ;-) ? This bug will allow javascript to be executed in RSS feeds. Typically, RSS feeds do not include Javascript, and the use of any other markup is limited/prohibited. But as any real standard, there are various implementation choices. This patch will fix the javascript issue in OS X's syndication component.

iChat

Last one... iChat! In response to the Leap.A worm/trojan/virus, this patch adds download validation to warn the user of unknown file types before downloading them. Apple considers this an enhancement.

Summary

lots of bugs, lots of patches. Sadly, Apple's security response appears to be deficient at this time. We can only hope that this is recognized as an inhibitor to the future growth of Apple in particular in professional environments. I like my (relatively new) iMac, and will spend more time digging into various security features of OS X in the future. Apple made a few very nice choices with OS X (e.g. heavy use of sudo vs. running as "Administrator"/"root"). However, compared to OS's like Linux, there are still a few features I am missing (mandatory access control?). Apple includes a number of well supported open source components in OS X. It has to develop a process to track updates to these components better. While Apple does not use a scheduled patch day, it opts to release a number of patches at the same time, combining the worst features of both worlds (Patch Day: Large number of patches at one time; No Patch Day: Unpredictable patch cycle).

This week, a story made the news about an experiment, where OS X was compromised within 30 minutes using a 0 day exploit. In this case, an authorized attacker was given shell access as a regular user, and he used a so far unpublished exploit to escalate privileges. True, this is an extreme case. Typically attackers do not have remote shell access, and a 0-day was used in this attack. But it highlights the need for defense in depth. OS X has most of the pieces in place (firewall, limited services enabled, use of sudo).