[Previous entry: "Yet another thing about the Maynor/Ellch affair"] [Next entry: "More on Ellch/Maynor"]
08/23/2006: "Ellch and Maynor: the continuing debate"
It goes like this...
1) The Apple Airport driver for the Intel notebooks (and Intel mini) uses a variant of the net80211 stack (and 'hal') from FreeBSD. If you search closely enough, you can find ample evidence.
Intel-MacMini:~ jim$ /usr/sbin/kextstat | egrep -i "80211|Airport"
92 1 0x940000 0x19000 0x18000 com.apple.iokit.IO80211Family (112.1) <39 16 11 6 5 4 3 2>
93 0 0x959000 0x60000 0x5f000 com.apple.driver.AirPortAtheros5424 (104.1) <92 39 16 11 6 5 4 3 2>
If you run 'strings' on /System/Library/Extensions/IO80211Family.kext/Contents/PlugIns/AirPortAtheros5424.kext/Contents/MacOS/AirPortAtheros5424 you'll find that the string table (at least) is quite similar to the "wlan.ko" driver (found in /boot/kernel) on FreeBSD-6. Try grepping for ieee80211_ in the output of both strings commands, and you'll see what I mean.
The lineage of the MacOS driver for the Atheros chipset is quite clear to anyone used to a) working with WiFi hardware and b) able to deal with kernel loadable modules on MacOS, BSD or linux.
2) It is highly unlikely that the 802.11 IE issue (which Maynor/Ellch promote in their defense) is present in any released version of MacOS. Apple didn't use Atheros 802.11 chipsets prior to the launch of the "MacBook Pro" and Intel Mac mini.
The "MacBook Pro" was introduced http://www.apple.com/pr/library/2006/jan/10macbookpro.html">Jan 10, 2006.
It didn't ship untilFebruary 14, 2006.
The Intel Mac mini wasn't introduced until February 28, 2006.
The SA for the FreeBSD 6.x was released January 18, 2006.
The problem was known (and understood) as far back as early November 2005
Atheros actually did the initial port of the net80211 stack into the MacOS 10.4 kernel. For all I know, they continue to maintain the code. Sam Leffler is the original author of the net80211 code used in FreeBSD (a variant of this code is known as the 'madwifi' driver on linux.)
It seems beyond reason to me that Atheros would not have fixed the net80211 stack for MacOS when the issue was well-known for three months before the initial shipment, and a known bugfix (patch) was released almost 30 days before the "MacBook Pro" began to ship. My bet is that Apple and Atheros (and Sam Leffler) had a fix for this well-before January 18, and the additional delays were due to the "process" required to get code incorporated into the RELENG_6/6.0-STABLE mainline.
If so, Ellch/Maynor pointing to the FreeBSD net80211 flaw is, at best, (yet more) misdirection.
Were I to guess (and I am), here's what probably happened.
1) Ellch and Maynor want to present the results of their 'fuzzing' research at BlackHat. One of them (likely Maynor) decides that they need a demo. Busting open Windows machines isn't news, and busting a linux or FreeBSD-based machine isn't any fun, because its not press-worthy.
But busting a company well-known for its secrecy that is currently touting itself as more secure than Windows PCs? Dude, the press might cover that!
2) Ellch and Maynor attempt the "Information Element Buffer Overflow" on at least an Intel MacBook, and can't get it to fail. They may have tried other Apple products and had them not fail either. I doubt that the firmware on the original, Lucent-based Apple Airport cards mishandles over-length IEs in received Beacon or Probe Response frames.
Sensing that their demo is doomed, they take a different tact. They find an 802.11 USB device. Maynor has some experience with USB device driver security. Maynor presented "0wn3d by everything else: USB/PCMCIA Issues" at CanSecWest 2005.
In it, Maynor proposes that in order to exploit DMA as a vector for a remote exploit, physical access to the machine is required, and then notes that Wireless, Bluetooth and Network drivers are exceptions t this rule.
Remote exploits via USB is theoretically possible but that Maynor did not show he had actually done it, so the value of his presentation dropped to near zero among technical people while it stayed quite high for non-techies and, most importantly, the press. Anybody can claim that this or that is insecure or flawed, the real hard work is proving it.
It’s been over a year since CSW 2005 and I still haven’t seen a technical paper or sample code that demostrastes the problem beyond any reasonable doubt. Modern research requires that you allow your peers to scrutinize your methodology and the results of your work otherwise its just a makreting campaign. Maximillian Dornseif presented a real attack using similar techniquies over FireWire at the same conference. The code is published. Now missing is a video of the exploit., which is too bad, as it could have been interesting. There appears to be a version of the same video here, though.
Maynor updated (and referenced) his CSW 2005 presentation at toorcon with "You Are The Trojan". Tellingly we find this admission on slide 47: "After working with the very diligent MSRC it was discovered only two of the bugs could lead to an actual overflow condition, and of those two one was not in a *.sys."
And thats on Windows...
Maynor's ToorCon and CSW presentations also contain what can only be described as adoring fanboy references to Maximillian Dornseif. Go take a look for yourself.
Lets return to MacOS though.
3) As noted before, it is expressly >NOT< possible to leverage the built-in Airport wireless device in the MacBook via over-length IEs in beacons or probe responses. This will not do.
4) Maynor and Ellch either find a 802.11 USB device that will forward over-length IEs, with a driver for MacOS, or they create enough of a stub driver to leverage these same over-length IEs. Note that this stub driver need only forward all over-length frames to a user-space process as commands to start a copy of 'nc' (as pointed out in previous posts.)
A simple approach for the demo would be to send the "nc" (or similar) command string over as an Information Element in beacon frames. A user-level process on the MAC could sit and read these frames, decode them, and start the remote process.
Its possible that Maynor and Ellch actually could (or perhaps even do) produce shellcode for the Mac while running in the context of the device driver. Anyone who has done even insignificant kernel work on MacOS or any Unix/linux kernel knows that its nearly trivial to start a new process running the command of your choice from kernel context, including the 'top half' of device drivers. (Its possible from the bottom-half too, but this would be very poor practice and brings about other problems.) This is a somewhat more difficult coding exercise, but it is possible, as long as the device driver will stay up long enough to accomplish copying in the remote exploit code.
Here the problem is that the device driver (if not the entire kernel) could go down like a $20 whore once the remote exploit code is run in kernel context. Who knows what your "remote DMA exploit" might have just trampled. If the device driver dies, then the USB-based WiFi access dies with it, severing connectivity.
For this reason, if Maynor and Ellch did not completely fake the video, I believe that they used an entirely userspace-based approach, but this approach requires them to have setup the MacBook well in-advance of the start of the demo, and, in fact, this is what we see. We see that 'en1', the internal Airport card has the IP address (192.168.1.50) referenced by Maynor in the video, and we see that the last two hex digits (6d) of the MAC address of en1 are present in the command that Maynor runs on the Dell. And, around 04:29 in the video, we can see that the Airport icon in the menu bar indicates that the Airport card (en1) is associated with an AP, though we don't know which AP.
The "userspace approach" would explain how the "remote shell" starts in Maynor's home directory on the MAC, and appears to be running as his UID, rather than 'root'.
Its also possible, of course, that Maynor started the "remote shell" himself. Doing so would completely destroy whatever credibility he has in the security industry, but he could always do a post-presentation "wax job" to polish the turd. He may or may not be busy doing so right now.
In summary:
Is it possible to overtake a *nix (or Windows) machine with a hostile device driver? Yes. I doubt that anyone is debating same.
Does the video show such an exploit? No, not unless the USB device is somehow used to 'trigger' the functional equivalent of the 'nc' command I showed in an earlier post.
Perhaps Maynor and Ellch found a USB card with enough of a driver that they could exploit the IE buffer overflow attack (or something a lot like it), and this is used to trigger either shell code (a full remote exploit) or to signal a copy of 'nc' (or its equivalent) already running on the box. A sort of "you may connect now". Typical covert channel stuff.
But what the video shows is that communication is *literally* taking place over the (internal) Apple Airport card. *IT* has the IP address, *IT* has a partially-matching MAC address, and, quite likely, *IT* is associated to the "AP" running on the Dell laptop.
Buggy device drivers that accidentally open holes for remote exploits is not news.
Hostile device drivers are not news.
Running a hostile AP is not news.
Running 'nc' is not news.
A full remote exploit is possible, but unlikely with the Apple Airport card.
Due to the unlikely coincidence of the remote shell starting in Maynor's home directory, we quite likely have not witnessed a remote exploit of the MacBook, even with the USB card in-place.
We're left with nothing except the fact that remotely 'fingerprinting' 802.11 devices (and driver versions) is interesting work, (this is what 'fuzzing' is) and could lead to the results that Maynor and Ellch wanted to present. But we still don't have a demo of an exploit.
No doubt one is possible, on several different kinds of cards.
And then there is this.
If you look at www.smallworks.com on www.technorati.com, and search through the inbound links, we come to an inbound link from "/media" and the following snippet:
it up with a live demo. *sigh* "No security researcher knuckles under to strong-arm tactics without watching his credibility be destroyed." --Jim Thompson * When I signed up to be a "security researcher" nobody ever mentioned that i would have to sacrifice my financial solvability by
80211mercenary.net is Ellch's blog. If you follow the /media link, it now contains two words, "Coming Soon!", but Technorati appears to have cached a much more interesting (and telling) entry by Ellch. In the cached entry, the '*' links to http://www.smallworks.com/archives/00000455.htm
Anyone who is familiar with the Technorati API and knows how to extract more of this entry is welcome to show me how. Google's cache is too new (August 18), and the Wayback Machine doesn't have any entry's for Ellch's site.
