Mac Developer mulling OS X equivalent of ZERT

Now that the Month of Apple Bugs project is done, Landon Fuller just wants some rest. Then, if his buddies are up to it, the brain behind the month of Apple fixes counter-project wants to expand the initiative to provide "zero-day patches" for critical issues affecting Mac OS X users.

"Perhaps [it could be] the Mac OS equivalent to ZERT," Fuller said, referring to the Zero-day Emergency Response Team, a group of respected security pros that offer unofficial patches during malware crises.

Fuller, a former engineer in Apple's BSD Technology Group and one of the primary architects of the Darwin ports system, believes there's a place for immediate, third-party patches when there's a legitimate threat of code execution attacks.

"I don't think I could ever survive another month of bugs," he says with a laugh. "[But] I'd like to see some longer lasting positive efforts result from all of this. In my day job, I'm the Director of Infrastructure for a small games company -- we have a number of Macs, and I'd like a tool for patching them if the need arises," Fuller added.

"This is more about providing the option, as well as fixing the issues for our own use. I kind of think of it as the open source ethos applied," he said.

Fuller's group started floating the idea for life after MOAB in mid-January when Sun issued a warning for a nasty code code execution flaw in Java's GIF image decoder. Because the vulnerability allowed the execution of arbitrary code within the JVM via any Java applet, Fuller created a temporary patch for Mac OS X. (Apple is responsible for porting and maintaining the Java Runtime Environment, meaning that Mac OS X users are still vulnerability to the Java GIF issue). "The Java bug is an example [of what we can do going forward]. I'd like to improve upon our code a bit, I've considered implementing some sort of secure auto-update feature," he explained.

Throughout the MOAB project, Fuller and a group of volunteers -- mostly close friends -- collaborated on a Google Group to respond to each reported issue with a runtime fix. The group spent between 2 and 8 hours a day coding and testing the fixes but deliberately punted on patching kernel bugs because, as Fuller explains, "the cost for a mistake in a kernel patch is very high."

Software vendors -- and security experts -- generally caution against using unofficial patches because of the risk of potentially violating support contracts or breaking existing applications but there's a strong argument that an emergency fix is better than nothing at all during zero-day malware attacks.

Fuller's team applied a buyer-beware tag to their fixes and positioned the project as providing an option for Mac OS X users who could have been at risk when MOAB flaw information was publicly released without Apple getting a chance to create patches. "There are absolutely downsides to third party fixes, and as a business, I'd be very, very careful before choosing to install one," he said, explaining that one of the advantages of his project was the use of runtime patches that could be easily removed or disabled.

The MOAB fixes team brainstormed the idea of coordinating with the MOAB hackers -- L.M.H. and Kevin Finisterre -- but, after some back-and-forth, decided against it. However, Fuller believes MOAB helped to raise awareness about insecurities in the Mac ecosystem, even if it was unfortunate that users were caught in the crossfire.

"I'm interested to see the ramifications that it has on the overall Macintosh security debate, if any. In the community, I do think that there is often a general dismissiveness of security concerns. I think that's very unfortunate, as these are very complex issues and I feel that they're important enough to deserve a fair evaluation. The Mac has a great security track record, but I think there's great value in asking "why?" he argued.