Today's patch includes fixes for three different issues:
Thanks to my friends William Carrel and Rosyna of Unsanity for their work on tracking down the bugs and assistance in implementing the patches.
You can download the source, or a pre-built binary. As always, you'll need Application Enhancer to use the patches.
Update 9:00 1/29/06: Modified the patch (to 27-1) to match the latest 10.4.8 version of the PowerPC Software Update.app, 2.0.5 (Intel is 2.0.4).
This release also removes a few patches:
The ever-handy Flip4Mac WMV QuickTime components are susceptable to a buffer overflow due to an integer overflow when comparing two buffer lengths as signed values. The comparison results in a stack-based buffer overflow that is potentially remotely exploitable by a malicious WMV movie. Both Mail.app and Safari will inline WMV movies (I accidentally crashed Mail.app when I tried to attach a proof-of-concept to an e-mail I'd drafted).
This patch is more complex; nearly all symbols are stripped in Flip4Mac, so finding the vulnerable code requires locating a public symbol and then computing the offset to the vulnerable code, for both PowerPC and Intel. Due to the relatively short length of the function in question, I decided to completely re-implement it, using proper unsigned comparisons. You can peruse the implementation in Google Code's web interface.
Software Update falls prey to a common format string vulnerability, passing the user-supplied file name to an alert panel. However, I'm not aware of any means of delivering a maliciously named file without requiring direct user interaction. The error dialog in question is only displayed when a file without the "sucatalog" extension is passed to Software Update (eg, "swutmp") -- the patch checks file extension, and escaps any '%' characters if the extension is not "sucatalog".
Installer is also susceptable to the same issue -- when an error is encountered while opening a file, Installer will pass the user-supplied file name to an alert panel. A zipped installer package will be automatically opened by Safari if "Open Safe Files" is enabled. The patch works by "context patching" NSRunAlertPanel() while within -[InstallerController openFile:withOptions:]. The guarded NSRunAlertPanel() passes it's msg argument as a vararg argument to the "%@" format string, and the patch is removed when -[InstallerController openFile:withOptions:] exits. A reference count is used to handle recursion.
Soon the month will draw to a close, and with it, The Month of Apple Bugs. Lest you think I've dropped off the map, I've set aside the weekend for addressing the new issues. Apologies for the delay -- it's been a busy work week!
I'm also pleased to announce a number of software updates for outstanding issues. The turn-around time on these updates is admirable.
The indubitably responsive developers at Panic have released an update to fix the ftp:// and ftps:// buffer overflow announced in the MoAB #19 advisory.
The good-natured fellows of Maxum Development Corporation have released an update to Rumpus, fixing the issues outlined in MoAB #18. Existing Rumpus 5.1 users may use the "Software Updates" feature in Rumpus to automatically download and install the update. All others can download the updated demo application.
Where a critical high-risk "0-day" issue exists, and is practical to patch, I plan on continuing to provide patches beyond the Month of Apple Bugs. The Java GIF Patch is the first of these "non-MoAB" fixes.
The MOAB Fixes group remains the primary point of coordination, and I expect to move this effort to a more official home than my own web log.
The latest MoAB issue is a format string vulnability in iChat. The proof of concept uses Safari's auto-handling of aim:// URLs to pass a 'aim:gochat?roomname' request to iChat.
The patch for the issue was adeptly implemented by William Carrel. His patch works by guarding -[ActiveChat showError: (NSString *) error] and escaping any format string specifiers in the error message. As always, patches are coordinated at the MOAB Fixes group if you'd like to participate.
You can download the binary, or the source. As always, you'll need Application Enhancer to use the patches.
This release also updates the patch for the Java GIF Heap Overflow issue. The update expands the library path regexes to ensure that Firefox-launched JVMs are always patched, in addition to Safari.
The expeditious fellows over at Maxum Development also have a fix in the works for the MoAB #18 issue in Rumpus, and will be releasing an update in short order. Cheers for their fast turn-around on the issue.
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.
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.
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.
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).
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.
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.
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)."
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:
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.
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.
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 ...
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.
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.
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.
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
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?
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!
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
I'm pleased as punch to report that the terrific WebKit team is looking into the issue.
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.
The magnificent VideoLAN team has released 0.8.6a, which fixes the MOAB-reported vulnerability. You can download it from their web site.
I'll be removing the patch for VLC 0.8.6 in tomorrow's APE release.
Q. Are patches cumulative? Do I need to install more than one APE?
A. The patches are cumulative -- each new version contains all the previous fixes (including improvements and bug fixes), plus the new fix. If a vendor releases a fix, we'll remove the patch from the APE bundle.
Q. When does a patch take effect? How do I know if I'm protected?
A. Application Enhancer will apply new fixes when an application is restarted. If you've just installed Application Enhancer for the first time, I suggest logging in/out, or restarting your computer.
Q. How can I determine what patch version I have installed?
A. The current version is displayed under the APE name in the Application Enhancer preference pane. The version corresponds to the day -- today is January 4th, and the APE version is 4.0.
Q. Do you support Panther? What operating systems are supported?
A. Unfortunately, only Tiger. I don't have the resources or time to test anything other than Mac OS X 10.4.8.
Q. What happens when the vendor (eg, Apple, VLC) releases a fix?
A. All of the patches are keyed to specific software versions, and the patches are applied at runtime -- the on-disk files are never modified. When a new release of the vulnerable software is installed, the patch will not apply itself. The APE can also be removed at any time by clicking the "-" button in the Application Enhancer preference pane.
Q. How can I contribute?
A. You are encouraged to join the MOAB Fixes group.
I'd also like to apologize to everyone whose e-mail I haven't yet been able to answer personally. I promise I'll reply, it may just take me a couple days.
Today's update was masterfully implemented by Finlay Dobbie, William Carrel, and the members of the MOAB Fixes Google Group.
Finlay solved today's Month of Apple Bugs issue -- a format string vulnerability in iPhoto's Photocast support. His patch guards the -[SubscribedAlbum registerPublishError:withTitle:] method, escaping all occurances of '%' in the title argument. -[SubscribedAlbum registerPublishError:withTitle:] passes the title directly to [NSString localizedStringWithFormat:].
William Carrel has skillfully updated the fix for the Apple Quicktime HREFTrack Cross-Zone Scripting vulnerability to use a whitelist exclusion method -- QuickTime movies will only permit http, https, and ftp URLs in the HREFTrack.
You can download the source, or a pre-built binary. As always, you'll need to install Application Enhancer to use this -- once it's installed, simply double-click on the Moab bundle to install the patch.
The third issue from the Month of Apple Bugs takes advantage of the interaction between web browsers and the QuickTime Plugin, leading to a cross-site scripting vulnerability.
The vulnerability allows an embedded quicktime movie, located on an external site (eg, an ad server), to execute javascript in the context of the enclosing page. Please note that the current 10.4.8 version of Safari does not appear to execute JavaScript from a QuickTime HREFTrack, and thus does not appear to be susceptible to this attack.
Today's fix involves patching the QuickTime Plugin's rNPN_GetURL() function, which is responsible for asking the browser to load a page. The patch replaces any javascript: URL requests with a javascript alert box that reads: "[MOAB] Blocked a QuickTime JavaScript Call. See http://landonf.bikemonkey.org/code/macosx/ for more information."
A huge thanks to both Alexander Strange and Rosyna of Unsanity for doing most of the work to track down the issue. I also owe a big favor to my friend William Carrel, who was kind enough to do a code review of the latest changes, and set up a new MOAB Fixes Google Group.
I'd also like to thank all those who have written kind e-mails, or sent other well wishes. It's very much appreciated.
You can download the source, or a pre-built binary. As always, You'll need to install Application Enhancer to use this -- once it's installed, simply double-click on the Moab bundle to install the patch.
As I mentioned above, William Carrel has set up a MOAB Fixes Google Group, where I will be coordinating bug fixes for the rest of the month.
In addition to the above fix, I've also updated the fix for the QuickTime RTSP issue. I fixed a bug in the argument handling (I miscounted the total number of arguments pushed on the stack), and I've added extra seat belts to ensure that the fix will automatically disable itself upon a new release of the QuickTime Streaming Component.
The astutely observant Aviv Raff noted that the QuickTime vulnerability permits Cross-Zone Scripting, which could allow QuickTime movies to access local reference protocol handlers, and potentially permit remote code execution, in addition to the cross-site scripting aspect we've already patched. Just to be safe, I'll be issuing an update later today with a more restrictive (whitelist-based) protocol filter.
Today's bug from the Month of Apple Bugs is a format string vulnerability in the VLC media player.
The wonderfully responsive and dapper VLC team already has a fix committed, and I'm sure a new release will be forthcoming.
In the meantime, more for completeness than necessity, I've added a fix to the MOAB Ape. The fix is keyed to (and only supports) the latest VLC release (0.8.6) -- the patch will automatically de-activate itself when you update VLC, which you should most certainly eventually do. The patch works by guarding the *_log_handler() callbacks, checking for format string characters before passing the string on.
You can download the source, or a pre-built binary. You'll need to install Application Enhancer to use this -- once it's installed, simply double-click on the Moab bundle to install the patch.
If you'd like to help with tomorrow's MOAB vulnerability please feel free to send me patches or other information. If there's enough interest, I'll fire up a mailing list.
I stumbled across the Month of Apple Bugs today -- a new Mac OS X vulnerability released every day for a month.
Today's vulnerability exploits a stack buffer overflow in the QuickTime Streaming component, and includes a working x86 exploit. More details available here. Short summary: if you visit a malicious web page, a remote attacker can execute code on your machine.
So, part brain exercise, part public service, I've created a runtime fix for the first issue using Application Enhancer. If I have time (or assistance), I'll attempt to patch the other vulnerabilities, one a day, until the month is out.
You can download the source, or download a pre-built binary. You'll also need to install Application Enhancer to use this -- once it's installed, simply double-click on the Moab bundle to install the patch.
I've had one report of the Moab bundle showing up in the Finder as a plain directory. If that occurs, try manually adding the bundle from the Application Enhancer preference pane, in System Preferences (Hit the "+" button).
The overflow is in the QuickTime Streaming component's INet_ParseURLServer() function -- the fix patches that function and pre-validates the URL before passing it off to the real function implementation. If the URL is too long, the patch replaces the Evil URL with a benign, but invalid one, and then calls the original function.
It's worth noting that disabling RTSP, as noted elsewhere, is (unfortunately) not necessarily sufficient -- there are other vulnerable entry-points to INet_ParseURLServer(), as it is used for generic URL parsing.
Please see this page for updates!