The Mac OS X Expert Challenge 2005.1
© Amit Singh. All Rights Reserved. Written in April 2005
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.
The Construction of Panpipes
For details on how I constructed the panpipes program, please refer to the document The Construction of Panpipes.
Perhaps the most intriguing aspect of the system flaw used by panpipes is the flaw's age. It has existed for well over ten years. NEXTSTEP, which is ancestral to Mac OS X, had the same issue, and the issue continues to exist in the current and upcoming versions of Mac OS X.
Response to the Challenge
The response was better than I had expected, for the most part. Consider the following key 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.
I received several other emails — some of them quite bizarre — that do not qualify as entries by any stretch of imagination. I am at a loss what to make out of notes such as the following (quoted verbatim):
- "I think you must be hacking the main frame to crash the kernal. Whatever you're program is doing, its hot stuff!"
- "While I haven't looked at your program, but have you checked permissions? I had my system crash at random times due to messed up permissions on my external drive."
- "Could you at least of provided a simple Cocoa GUI for your program? Terminal app programs are not very popular with Mac people, you know."
- "Who do you think you are for insulting people like this?"
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):
Please note that barring cases where I have received correspondence, I have no way of knowing whether a downloader actually attempted to analyze panpipes or even executed it. Specifically, downloading panpipes does not necessarily imply that the downloader participated in the challenge.
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.
I had stated my goals for this endeavor as the following:
- Probe popular interest in system-level Mac OS X topics.
- Gauge the initiative and inquisitiveness of the Mac OS X community based on the kind of response generated.
- Use the outcome to roughly quantify, if possible, Internet-wide Mac OS X expertise outside of Apple.
- Facilitate sharing (and acquisition) of Mac OS X knowledge.
- 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.
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
icbimnemonics, 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
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.
In my opinion, an important positive side effect of this challenge is that at least the techniques used by panpipes become public knowledge. This should reduce the size of the conceivable arsenal of "unknown tricks" that could potentially be part of future malware.