Uninformed: Informative Information for the Uninformed

Vol 8» 2007.Sep


OS X has a strange place in the hearts and the minds of the research community. Security researchers, like most other users, enjoy a well-built and reliable hardware platform topped off by an operating system with a slick interface. Switch gears from the users experience to a more research-oriented focus and problems start to appear. Researchers have historically explored and documented internals of operating systems like Microsoft's Windows and open source counterparts such as Linux and BSD variants. The knowledge gaps for OS X are in no way a show stopper for researching security vulnerabilities on OS X; still, they prove to be a frustrating speed bump. While static analysis of binaries in a Windows environment may be trivial, the same cannot be said to be true on OS X. This document contains information collected from a variety of sources after discovering a flaw in a wireless device driver for OS X.

Before the accidental discovery of the wireless flaw, the author knew next to nothing about the internals of OS X, the ``xnu'' kernel. Google, in a rare failure, also provided next to no help. All the articles the author encountered only narrowly covered a topic without talking about how one could go about building a useful research environment. Many of these articles talked about something each respective author discovered without showing how others could rediscover it. For this reason, the author includes tips throughout this paper in the form of sections entitled ``Things I wish Google told me''.

The Test Network

Many elements are required when finding and duplicating a wireless vulnerability. Since the target for the attack described in this paper is running the OS X operating system, at least two OS X machines are needed for kernel debugging with gdb (the ``GNU Debugger''). A third computer with a D-Link WDA-2320 Atheros based card is used as the attacking machine. The attacking machine uses a small Linux based distribution that runs from a CD called BackTrack2[5]. BackTrack2 is used because it includes many special 802.11 drivers that are capable of raw packet injection, a feature that most wifi drivers (frustratingly) lack.

The author's initial research on the subject described in this paper made use of a patched version of ``Madwifi-old'' with LORCON. Madwifi is the name of the open-source drivers for chipsets from Atheros. LORCON is a wifi fuzzing tool written by Josh Wright. Since quick and flexible packet generation is important, the original tool used for this research was ``scapy'', a packet creation engine written in Python. The examples in this paper, written almost one year later, make use of the Metasploit LORCON integration and are written in Ruby.

To help provide some perspective on the research environment used in this document, the following three machine configurations should be referenced:

Target Machine
Hardware Mac Mini, 1.66Ghz, 512MB RAM
OS Version 10.4.7
IP Address
Role The target machine is the victim in the testing scenario. It is running a vulnerable version of the OS X Atheros driver.
Dev Machine
Hardware Macbook, 2GHz Intel Core Duo, 1 GB RAM
OS Version 10.4.7
IP Address
Role This machine runs gdb for connection to the target machine. It is also setup as a core dump server, but that functionality appears broken. This box will also archive the panic logs and register information along with stack traces. This is the primary machine for single step debugging.
Attack Machine
Hardware Generic shuttle PC, Pentium 3, 512MB RAM
OS Version Backtrack2 Bootable Linux CD
IP Address
Role This is the attacking machine. The attack initially launched from a Dell Laptop with a PCMCIA card. This machine is close to the same specifications with an Atheros based D-Link card. The attacks are in Ruby using the Metasploit framework integration with LORCON.