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 ...
Generally speaking, a software vulnerability is usually announced in coordination with a vendor-supplied software update. However, there are cases when a vendor patch is not available for a critical software vulnerability, leaving the user with limited options. Relatively recently, the idea of a "third party patch" has emerged; when a vendor patch is not available, a third party can reverse engineer the software in question and produce a temporary bug fix.
This technique has previously been used for both unpatched Windows and Mac OS X vulnerabilities. In 2006, Alexander Sotirov presented "Hotpatching and the Rise of Third-Party Patches" at the Las Vegas Black Hat conference, and is responsible for implementing two patches for unfixed Internet Explorer vulnerabilities. ZERT (Zero-day Emergency Response Team), who is composed of an impressive array of individuals, "work(s) together as a team to release a non-vendor patch when a so-called '0day' (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the Internet or both." On the Macintosh, Unsanity released Paranoid Android, a run-time patch for a critical vulnerability in Mac OS X's document handling. I believe the award for the first third party Windows patch for an unfixed vulnerability goes to Ilfak Guilfanov's December 2005 WMF patch. Guilfanov is the author of the excellent IDA Pro disassembler and debugger.
A vendor-supplied update is always preferable to a third party patch. Third party patches are created by reverse engineering the vulnerable code, and are subject to limited testing and potential implementation deficiencies -- like the author of the vulnerable software, patch implementors are human, too. It is always possible that a bug in the patch could result in instability, or potentially expose a new exploit scenario.
On the other hand, a third party patch can provide protection against a critical vulnerability before the vendor is able to implement, test, and release a fix. The decision to use a third party patch should be made after a careful assessment of the vulnerability's risks and your own requirements -- it's never unreasonable to wait for an officially provided vendor fix.
The patches we've provided have all been implemented using Unsanity's Application Enhancer, and are "run-time patches" -- the patches insert themselves into applications at runtime, find the vulnerable code, and apply a band-aid. Nearly all of the patches released so far work by wrapping the vulnerable code and providing additional data validation, rejecting data that would otherwise cause the vulnerable code to malfunction (and thus allow the exploit to succeed). There are other options for implementing run-time patches on Mac OS X, including the open source mach_star -- I've previously used mach_star to implement runtime security patches for software on my own Mac. However, for the purposes of providing these fixes, I decided upon Application Enhancer.
Application Enhancer provides a nice, easy to use GUI for installing Application Enhancer Modules (Haxies), such as the patches we have been providing. It also provides some important features for ensuring the safety of a patch:
The use of a runtime patching framework also assures that we can provide patches that meet our own safety requirements:
"Wait!", I hear you saying. What about the latest Month of Apple Bugs issue (MOAB-08-01-2007) in Application Enhancer?
The vulnerability is real -- it is possible for a local administrator account on the computer to gain root access, without any user confirmation, by replacing pieces of Application Enhancer's installation. While this can not be exploited remotely, it could be used in combination with a remote exploit to acquire escalated privileges. However, a remote exploit alone is sufficient to allow an attacker full access to your important personal data.
This issue is part of a larger collection of vulnerabilities that take advantage of the admin-writability of directories in /Library and elsewhere, such as the Apple DiskManagement BOM Privilege Escalation Vulnerability, or the /Library/StartupItems vulnerability fixed in 10.4. In this case, administrators are allowed to write to /Library/Frameworks, and Application Enhancer launches one of its binaries from /Library/Frameworks as the root user. As a work-around, you can change the permissions on /Library/Frameworks.
While I can't promise that I, or other MoAB Fixes members won't make mistakes, I can promise that we'll try our best to mitigate the critical issues as they are released. It's up to you to decide whether to install the patches, or wait for Apple's own patch. And if by some chance a critical error is found in one of our patches, we'll turn around a fix as fast as we can make one.
Please feel free to stop by the MoAB Fixes group with any questions, or send me an e-mail!