contents

Art | Automotive | Computing| Résumé|

meta

book

adsense

The Mac OS X Expert Challenge — 2005.1

Report

Recapitulation

I announced The Mac OS X Expert Challenge — 2005.1 a week ago. The challenge involved a program called "panpipes" that causes a Mac OS X system to panic. Moreover, panpipes incorporated certain cloaking measures to hide its operation. Participants had to analyze the program to determine its operation, provide their own program to trigger the same kernel panic, and propose a fix for the flaw in question.

Response to the Challenge

The response was better than I had expected, for the most part. Consider the following key statistics:

Statistics

• The challenge was open for 6 days and 15 hours.
• The challenge page was viewed over 8000 times.
• The panpipes program was downloaded 1071 times during the challenge.
• There were 5 entries to the challenge.

Net-demography of those interested

It is worth noting, and should be of particular interest to the winners, that there were downloads from research labs, universities, and technology companies.

Consider the following non-exhaustive list of examples (University names are colloquially stated):

Laboratories: Fermi National Accelerator Laboratory, Goddard Institute for Space Studies (NASA), Los Alamos National Laboratory, Lawrence Livermore National Laboratory, and Sandia National Laboratories.

Universities: ANU (Australia), Boston University, Brown, Caltech, Cambridge (UK), Cornell, Universidad Galileo, Harvard, Hokkaido (Japan), Imperial College (UK), Indiana, Iowa State, John Hopkins, Kent (UK), L'Univerité de Nantes (France), Maryland, MIT, Monash (Australia), Michigan, Newcastle (UK), NTUA (Greece), Ohio, Oregon State, Oxford (UK), Penn State, Portland State, RIT (Rochester), Rutgers, Stanford, Tennessee, UCLA, UTA (Austin), Utah, Various *.uni-*.de, Washington, Waterloo (Canada), University of Western Australia, and Yale.

Companies: Apple, Boeing, Capital One, Cisco, Compaq, Compound Therapeutics, EFI, Fossil, Goldman Sachs, GPC Electronics (Australia), IBM, IKEA, JVC, Microsoft, Motorola, nVIDIA, Oracle, SAAB, Tour Andover Controls, and Xerox.

Summing Up

I had stated my goals for this endeavor as the following:

1. Probe popular interest in system-level Mac OS X topics.
2. Gauge the initiative and inquisitiveness of the Mac OS X community based on the kind of response generated.
3. Use the outcome to roughly quantify, if possible, Internet-wide Mac OS X expertise outside of Apple.
4. Facilitate sharing (and acquisition) of Mac OS X knowledge.
5. At the very least, provide an interesting problem for some people to solve.

In light of my goals, one can question whether the challenge was useful to the audience, and whether it was useful to me.

Audience Feedback

Based on the feedback I received, I believe this endeavor was useful to its audience. Following are some excerpts from the feedback:

• "I took this challenge as an opportunity to learn something I knew little about. These hours were as filled with learning as I could imagine :-)"
• "I have never analyzed a security vulnerability before. In order to get to where I am now, I had to learn from scratch how to debug an OS X kernel and use gdb. I had never done either before. I thoroughly enjoyed it."
• "I didn't figure this out, but not figuring it out was quite educational. Even though I didn't find a solution, I learned a hell of a lot playing with this and it was definitely worth the six hours or so that I spent on it. Specifically, I learned about the sc, sync, isync, and icbi mnemonics, and how to write PowerPC self-modifying code. I learned all about syscall, and a bit about the dyld startup environment. I learned how to specify a function that is called lazily at init. I learned about ktrace and kdump, and how to remotely debug a kernel."
• "[I considered this challenge] as an example of how a working professional in the Apple support business is likely to respond to this type of malware."

My Feedback (to the Audience)

Rather than impose my inferences upon others, I would like to suggest the following points for pondering, which could potentially be topics of discussion based on the statistics of this challenge:

• The cloaking measures used in the construction of panpipes, and the approaches used in its deconstruction, are representative of creation of both malware and defenses against malware. "Defenses" include actions such as identification, dissection, prevention, removal, and so on. Note that real-life malware is capable of being far more sophisticated than panpipes. In simpler terms, one would need such skills both to "protect" and "attack" Mac OS X.
• One camp firmly believes that the paucity of malware on Mac OS X is simply because of its tiny user-base. Thus, there is little incentive for attackers.
• Another camp firmly believes that the paucity of malware on Mac OS X has nothing to do with its tiny user-base. Even if attackers were (or are) very interested in Mac OS X, they would not succeed.
• The flaw used by panpipes has existed unnoticed for over a decade. If attackers were indeed actively looking for flaws all along, did they miss this one? If nobody was ever looking for any flaws, could there be more exploitable flaws lurking?
• Given the nature of the marriage of Mach with Unix-like code (and other components such as the I/O Kit), there is scope for subtle flaws that may not be obvious unless one is proactively looking for flaws.

Further Discussion

Please feel free to use this thread on Kernelthread Forums for further discussion on this topic.

Acknowledgments

Special thanks to my friend Ted Bonkenburg for having valuable discussions with me on various topics.

All contents of this site, unless otherwise noted, are ©1994-2006 Amit Singh. All Rights Reserved. Terms of Use

Hosted at Jaguar Technologies