23:47 Sat, 20 Jan 2007 PST -0800

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

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.

[/code/macosx] permanent link