By John Gruber
Instabug: Understand how your app is doing with real-time contextual insights from your users.
Most of the time, when I report about something, the job is organizing, ordering, and explaining the facts. With the Maynor/Ellch/SecureWorks MacBook Wi-Fi security saga, however, it’s always been about missing facts. Explaining what we don’t know, rather than what we know.
More than six months have passed since I wrote “The Curious Case of the Supposed MacBook Wi-Fi Hack”; in hindsight, I wouldn’t hesitate to call it the most difficult article I’ve ever written.
The whole thing is back in the news because last week David Maynor broke his silence, both on his weblog and at a security conference. Glenn Fleishman’s initial report and follow-up offer the best coverage I’ve seen regarding Maynor’s new presentation.
But it’s all still rather unsatisfying, to say the least, because there’s still so much information that hasn’t been revealed.
What I find noteworthy is that the demonstration Maynor provided this week was an exploit that caused a kernel panic in a MacBook running Mac OS X 10.4.6. The video demonstration from August’s Black Hat conference that caused such a sensation was of a supposed exploit that resulted not in a crash, but in a hijacking, with root privileges, of the target MacBook.
In a comment on Fleishman’s post on Wi-Fi Networking News, Maynor writes:
Umm..I did release the code, it should be showing up on websites at any time. The code proves you can control both a broadcom based powerbook and an atheros based macbook. The only thing missing from the code is the weaponized shellcode which is part of a talk I am doing in a few months.
I.e. he claims to have released code that can cause these machines to crash, but has not released “the weaponized shellcode” that results in a hijacking of the machine. To my knowledge, however, even the code he claims to have “released” remains unavailable to the public.
Here are the questions I still care about:
Their demo video led to confusion because the hijacked MacBook in the video was equipped with a third-party Wi-Fi card and driver. The initial reaction to the video — no doubt fueled by The Washington Post’s Brian Krebs’ headline “Hijacking a Macbook in 60 Seconds or Less” — was based on the misconception that they had shown an exploit of a stock MacBook using the built-in AirPort card and driver.
The external card is clearly visible in the video, and Maynor explicitly states on camera that it’s what they’re exploiting. So this confusion was unfortunate, and I suspect, has clouded perception of the entire saga ever since. Many people remain under the impression that the controversy is about whether they used a third-party card or not, a fact which was never actually in dispute.
But the actual exploit on the video has never been proven or explained. Maynor and Ellch refused to reveal the make and model of the card, on the grounds that they wanted to provide the vendor with time to issue a software update to address the problem. It’s now six months later, and they still haven’t revealed what card they plugged into the MacBook for this exploit. Why?
In Jim Thompson’s analysis of a high-resolution version of the video, he observed that the networking interface in use on the MacBook has a MAC address in a range assigned to “Apple Computer”. (Every Ethernet device in the world has a unique MAC address; they are assigned in blocks to the manufacturers of Ethernet devices.) Thompson wrote:
Something stinks. Maynor explicitly states that he isn’t using the internal Apple Airport card, but this is the card with the IP address.…
The important thing here is to note the lack of a USB device in the IP interfaces listed. In a very real sense, I find it likely that the USB device is a McGuffin. A distraction.
In other words, there was a false controversy that these guys tried to pass off an exploit against a third-party Wi-Fi card as an exploit against the built-in MacBook AirPort card, but there is a real controversy that is converse of the false one — that their video purports to show an exploit against some still-unnamed third-party card but in fact shows a MacBook that is connected to the network using its built-in AirPort card.
If the video is legitimate, I see no reason why Maynor and Ellch can’t now release the make and model of the card and driver purportedly exploited in their video, along with the code and instructions to reproduce the hijacking.
How many third-party USB Wi-Fi cards even worked with Intel-based Macs last summer?
If so, what Macs? What versions of Mac OS X? Could they have won my challenge if they had chosen to accept it? (I remain confident they could not; however, it seems entirely possible they could have achieved a draw by causing the machine to crash.)
Why, for example, was the demo Maynor showed last week against Mac OS X 10.4.6 rather than 10.4.7? After he caused a kernel panic on 10.4.6, Maynor rebooted the machine into 10.4.8 and showed that the exploit no longer worked.
But Mac OS X 10.4.7 was released on June 27, 2006, more than a month before Maynor and Ellch announced their exploit. Maynor rebooted into 10.4.8 last week to show that the patches Apple released on September 21 — after Maynor and Ellch’s announcement in August — fix the problems exploited by his demo, indicating that despite Apple’s protestations, he and Ellch deserved credit for those fixes.
But if his exploit doesn’t work against 10.4.7, it might indicate just the opposite: that Apple’s September AirPort security patches were not directly related to this particular exploit against 10.4.6.
The exploit Maynor showed this week causes a kernel panic. That’s bad, but it’s far removed from the “take over the machine” hijacking shown in their video (and which served as the premise of my challenge). In his Q&A-style weblog entry this week, Maynor writes:
I thought you said it was a hijack yet you only showed a DoS.
Yup, I showed a crash. I didn’t feel the need to do the entire hijack for two reasons: Apple already confirmed that this vulnerability leads to remote code execution (they said so in the advisory here).
It’s unclear, to me at least, what he’s implying by “I didn’t feel the need to do the entire hijack”. Does he have such a hijacking exploit but chose not to demo it publicly (e.g. so that those in the audience sniffing the traffic couldn’t grab it)? Or does he mean that he didn’t see the need to develop such an exploit, even though he believes it is possible?
I think he’s implying the latter — i.e. that the crasher, combined with Apple’s description in the security update release notes, proves that a hijack exploit is possible via this same vector. Apple’s release notes state:
Impact: Attackers on the wireless network may cause arbitrary code execution
(Emphasis on “may” added.) Apple uses this language for just about any buffer overflow bug, however. In fact, a cursory examination of the release notes from other recent security updates indicates Apple uses it for all of them. This could mean many very different things. It could mean that it has been shown to allow arbitrary code execution, and that Apple is using “may” euphemistically. It could mean that Apple is aware that it allows arbitrary code execution, but only under certain (perhaps rare) conditions. Or, it could be that Apple’s engineers don’t know for sure whether it’s possible, and have neither been shown such an exploit nor found one themselves.
I say: Show me.
I believe that the exploit Maynor showed last week is exactly what he says it is: a denial of service attack against MacBooks running 10.4.6 that he and Ellch discovered last summer. If so, I wish that he’d been able to announce this sooner; it’s quite obvious that Maynor’s then-employer, SecureWorks, forbade him from presenting evidence to defend his claims.
But I don’t think this exploit can necessarily be expanded into a reliable hijack. We’ll know more if and when Maynor releases code for his exploit, which he’s promised to do.