23:03 Thu, 18 Jan 2007 PST -0800

Month of Apple Bugs - Day 17

The Bug

The 17th Month of Apple Bugs issue is a buffer overflow in the legacy SLP daemon. The code in question manages local service registrations on the /var/run/slp_ipc unix domain socket, and the vulnerable appears to be local only.

The buffer overflow is in SLPInternalProcessHandlerThread::HandleCommunication()'s kSLPRegisterURL/kSLPDeregisterURL handler:

char    attributeList[1024] = "";
memcpy( &attributeList[strlen(attributeList)], attributeListPtr, attributeListLen );


If you're concerned about the issue, disabling SLP is straight-forward, and should not result in a loss of functionality for most users. SLP has not been used for service registration since Mac OS X 10.2, and the slpd daemon is used only to register and announce SLP services to legacy clients. As far as I'm aware, SLP is only started when "Personal File Sharing" is enabled -- however, you won't need to disable File Sharing to disable SLP.

To disable slpd, open /Applications/Utilities/Directory Services.app and deselect "SLP" in the "Services tab. You can re-enable slpd in the same way. To make sure that the SLP daemon is stopped, restart your computer or kill the daemon from Terminal.

Thanks to 'MaxP' of the MoAB Fixes group for determining when, and how, slpd is started.

[/code/macosx] permanent link

23:39 Tue, 16 Jan 2007 PST -0800

MoAB Day 16 - Colloquy

Today's MoAB issue is another format string vulnerability, this time in Colloquy.

The amazingly prescient Colloquy team has already committed a fix, and a new build is available. The issue was noticed and fixed by the Colloquy team prior to the public release of the advisory due to active use of the vulnerability on the freenode network. The MoAB project disclaims responsibility:

"This is an unfortunate prank, and has no relation with us at all
(except the fact of developing the proof of concept and distributing it
to some people)."

[/code/macosx] permanent link

20:52 Sun, 14 Jan 2007 PST -0800

Keep on Keepin' On


I've been quiet for a few days, (although the group remains active), so I thought I'd write a short status update. For the past few days, the MoAB project has been releasing primarily kernel issues in filesystem (UFS & HFS) and network protocol handling (AppleTalk). While it is technically possible to patch the kernel, I am reminded of a Monty Python quote:

Hello. Now, don't you worry. We'll soon have you cured.
Leave it all to us. You'll never know what hit you.

The stakes are much higher when patching the kernel: a mistake can cause a system crash, complete with the potential for file system corruption and data loss. Count me out -- I don't want to provide a cure that's worse than the disease.

Instead, I recommend some simple steps to help keep yourself safe:

Other Limitations

Application Enhancer won't (as opposed to can't) patch applications owned by another user for security reasons -- this includes root. I have some code based on mach_star that I have previously used to patch various daemons -- if an issue is announced in a non-user process, I'll look into re-using that code, but it'd be a mighty shame to lose Application Enhancer's functionality.

Alternative Solutions

If you have any thoughts on providing patches for the previous issues, please do drop by the MoAB Fixes group. Matt Beaumont has been working on some ideas regarding pre-mount file system validation (custom tool, or fixed fsck), and could use a hand. I've done some work on deciphering the private DiskImages.framework, and have some code that implements support for pre-attach restrictions on disk images.

[/code/macosx] permanent link

21:13 Mon, 08 Jan 2007 PST -0800

Anatomy of the Runtime MoAB Patches


For the past few days I've been releasing patches for software vulnerabilities in an assortment of Mac OS software. This project was intended to be a technical one, and I've never sat down to explain, in clear terms, how the patches work, what Application Enhancer is, or what the potential risks are in running these patches. I'm also not the first one (not by a long shot) to think of implementing third party patches for unpatched software vulnerabilities, either, and I'd like to discuss those efforts.

Here goes ...

Click here to read more ...

[/code/macosx] permanent link

16:29 Mon, 08 Jan 2007 PST -0800

Month of Apple Bugs - Day 8

Today's Month of Apple Bugs issue exploits Apple's permissions on /Library/Frameworks to implement local admin to root user privilege escalation. Their proof of concept is Application Enhancer, the tool we've been using to apply run-time patches.

The proof-of-concept local exploit backdoors the aped binary by creating their own replacement framework in /Library/Frameworks. This allows a local administrative user to gain root privileges without supplying authentication credentials. It is the same sort of file system privilege problem that allowed Apple DiskManagement BOM Local Privilege Escalation Vulnerability, and the older /Library/StartupItems admin-writability issue.

Like the previous local exploits, this could be combined with a remote exploit to gain root privileges from an administrator account without user interaction. There are also a number of alternate exploit conditions that could occur due to the admin-writability of other directories in /Library.

One work-around:

sudo chmod g-w /Library/Frameworks

Reversed by running:

sudo chmod g+w /Library/Frameworks

Running "Repair Permissions" will also reverse the changes, but see this, first.

I'd like to state that Unsanity, the authors of Application Enhancer, have provided considerable assistance, and I have respect for their technical abilities.

[/code/macosx] permanent link

21:41 Sun, 07 Jan 2007 PST -0800

Month of Apple Bugs - Day 6 Fix Released

Today's Patch

After much wrangling, I've cooked up a patch for the denial of service bug in Apple's PDF implementation, detailed in MOAB-06-01-2007.

The patch implements loop detection in CoreGraphic's CGPDFReaderGetPageDictionary(), safely exiting the loop after 500,000 iterations (takes approximately 1 second on my machine). By way of comparison, the full ISO C99 specification PDF hits a maximum recursion count of 24. I'd like to thank the venerable William Carrel for his time reviewing the code, and his ideas on implementing recursive functional call handling. Thanks also to Rosyna of Unsanity for assisting in debugging Core Graphics.

The patch prevents the proof-of-concept PDF from locking up any application that uses the CoreGraphics PDF library, including Safari and Mail.app. Since we're unable to patch mdimporter, it will still temporarily fall into an infinite loop on nefarious PDF files -- fortunately, mdimporter detects the loop and exits.

You can download the source, or the pre-built binary. This release removes the VLC fix, so make sure that your VLC player is up to date.

MoAB Collaboration

I'd like to thank everyone for your input.

As I previously stated, I respectfully disagree with the decision to release exploits with no vendor notification. I must also stress that I am not a security researcher, and as such I strongly prefer to recuse myself from the heated debate and focus on providing fixes.

I think that I will have to respectfully decline LMH's offer of coordination. I genuinely appreciate the gesture of goodwill, but I don't feel that it is the right thing to do. I know some of you will disagree with me (and some will agree) -- but upon further reflection, I can't personally compromise the ethical point, though the offer may make my life easier.

I hope you'll all understand, and we can get back to bug fixes quickly. A sincere "thanks" to LMH and MoAB for the offer.

[/code/macosx] permanent link

15:33 Sun, 07 Jan 2007 PST -0800

MOAB Day 7 - OmniWeb

The ever-talented OmniGroup has already released a fix for this morning's Month of Apple Bugs issue. Talk about snappy! Today's issue is a format string vulnerability in OmniWeb's javascript alert() handler.

Download the latest update to OmniWeb at from OmniGroup

[/code/macosx] permanent link

14:44 Sun, 07 Jan 2007 PST -0800

Early Access?

LMH of the MoAB contacted me regarding coordination of fixes. He has posted the conversation.

I should state outright that I respectfully disagree with the decision to release exploits with no vendor notification. I also am not a security researcher, and as such I strongly prefer to recuse myself from the heated debate and focus on providing fixes.

That said, the initial goal of this effort was to have some fun, and to provide a quick fix for some serious issues. I never expected anyone to notice, and was perfectly comfortable labouring away in quiet obscurity. Lots of people noticed, however.

What do you think? Is it worth coordinating? Is it worth continuing providing fixes?

[/code/macosx] permanent link

00:47 Sun, 07 Jan 2007 PST -0800

Month of Apple Bugs - Day 6

Got a late start today -- I will be releasing the fix for today's MOAB issue tomorrow morning, to give me time for proper testing and a code review. The fix implements stuck loop detection, mitigating the proof-of-concept DoS on CoreGraphic's PDF implementation.

More details tomorrow!

[/code/macosx] permanent link

19:24 Fri, 05 Jan 2007 PST -0800

Month of Apple Bugs - Day 5

Ever feel like you're watching a game of table tennis? I've never been very good at the game ...

Today's Month of Apple Bugs issue permits a local admin account to gain root access, without any user interaction (ie, an authorization dialog), by exploiting a combination of vulnerable disk permissions and Disk Utility's repair permissions functionality.

When coupled with a remote exploit, such as the Month of Apple Bug's Quicktime RTSP URL Handler vulnerability (patched in the current Moab Ape), today's bug could allow the remote exploit to gain immediate root without any user interaction.

Due to the nature of the bug, a safe runtime patch is not viable without modifying on-disk file permissions.

If you'd still like to protect yourself, the Month of Apple Bugs project provides a temporary work-around in their advisory:

sudo chmod -s /System/Library/PrivateFrameworks/DiskManagement.framework/Resources/DiskManagementTool

This may have an impact on other Disk Utility functions -- you can reverse the work-around as follows:

sudo chmod +s /System/Library/PrivateFrameworks/DiskManagement.framework/Resources/DiskManagementTool

Update on the QuickTime Cross-Zone Issue

I'm pleased as punch to report that the terrific WebKit team is looking into the issue.

Darwin ... Ports! Ports!

A number of publications have done the architects of Darwin a disservice by stating that I'm "one of the principal architects of Apple's BSD-based Darwin operating system core". I just want to set the record straight: I originally wrote DarwinPorts (now MacPorts), with Kevin Van Vechten and Jordan Hubbard. Darwin was architected by minds far brighter than my own.

[/code/macosx] permanent link