MoAB #19, Java GIF Buffer Overflow, and more ...

20 Jan 2007, 15:39 PST

Today's post contains a whole slew of goodness:

More details follow, but for the impatient, you can download the source, or a pre-built binary. You'll also need to install the ever-handy Application Enhancer. See the FAQ for more information. As always, these third party patches are unsupported and without warranty. Please take a look at Anatomy of the Runtime MoAB Patches for more information on the history of 3rd party patches, and their risks and benefits.

MoAB #19: Panic's Transmit

The 19th MoAB advisory documents heap-based buffer overflows in Transmit's handling of ftp(s) URLs. Don't Panic, however -- we have a patch, and Panic is hard at work on an update to fix the issue. The illustrious William Carrel is the author of today's patch.

He tracked the issue down to the -[FTPConnectionWorker _connectTo:port:user:password:initialPath:localPath:redial:listFiles:encoding:] method, where strcpy() is used to copy the user, password, and host to 64 byte arrays. William's patch checks the length of the host, user, and password arguments; if they're too long for the fixed length buffers, the arguments are replaced with dummy, known-safe strings.

Java Extra Credit: Patching the Java GIF Buffer Overflow

This is the first patch for non-MoAB bug, and I'm interested to hear what everyone thinks about providing "0-day" patches to other critical issues.

On January 16th, the Zero Day Initiative released an advisory on a heap overflow in Java's GIF image decoder. The vulnerability allows the execution of arbitrary code within the JVM via any java applet. Sun has released an update, and if you're running a Sun-supported operating system (Linux, Windows, or Solaris), I strongly suggest upgrading.

On the Mac, however, Apple is responsible for porting and maintaining the Java Runtime Environment. It is apparent from my observations of the FreeBSD Java project that preparing and testing a new Java release is an expensive and time consuming process, least of all due to the extensive testing required of Sun licensees. With some prodding from Eric Hall, a friend and security consultant, I decided to release a temporary patch for the issue until Apple can release an official update.

The patch works by guarding the vulnerable Java_sun_awt_image_GifImageDecoder_parseImage(), checking for a image block width of 0, which causes a too-small buffer to be allocated and written to. When a width of 0 is found the patch's guard function throws an ArrayIndexOutOfBoundsException, and the vulnerable code is not run. The MOAB Ape patches both the Java 1.4.2 and Java 1.5.0 runtimes.

Are you sure you want to mount that disk image?

Also included in today's update is an optional feature that requires user confirmation before mounting a disk image, even if "Open 'Safe' Files" is enabled in Safari. The following message is displayed:

A number of disk image-related security issues have
been publicly disclosed, including denial of service
and potential remote code execution vulnerabilities.
Do you still wish to mount this image?

If you'd like to disable the message, simply deselect the "Warn before mounting disk images" in the MOAB Ape preferences (System Preferences -> Application Enhancer -> Moab).

Patching MoAB 5, 8, 15 with Bom-Shelter

If you'd like to fix your local disk permissions to prevent the admin to root issues outlined in MoAB issues 5, 8, and 15, William Carrel has written BOM Shelter -- a tool that corrects the disk permissions hilighted in MoAB issues 5, 8, and 15. You can read all about it on William's Blog.

Month of Apple Bugs - Day 17

18 Jan 2007, 23:03 PST

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

MoAB Day 16 - Colloquy

16 Jan 2007, 23:39 PST

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

Keep on Keepin' On

14 Jan 2007, 20:52 PST


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.

Anatomy of the Runtime MoAB Patches

08 Jan 2007, 21:13 PST


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

Read more ...

Month of Apple Bugs - Day 8

08 Jan 2007, 16:29 PST

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.

Month of Apple Bugs - Day 6 Fix Released

07 Jan 2007, 21:41 PST

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

MOAB Day 7 - OmniWeb

07 Jan 2007, 15:33 PST

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

Early Access?

07 Jan 2007, 14:44 PST

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?

Month of Apple Bugs - Day 6

07 Jan 2007, 00:47 PST

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!