Why The Washington Post Needs Actual Journalists

Update: There is a significant update on this on my later post, in which I not only admit to having been swayed by the press hype but also make an effort to clear a lot of things up.

Update: I've posted a reply to Thomas Ptacek's rather misguided mis-quoting of this post that new visitors might want to read - as always, you are free to make up your own mind where it relates to the attempts at logical arguments from such kind of writing.

People interested in knowing more may also want to read Jim Thompson's post regarding the video until there is some sort of open peer review of the underlying technique.

Since I'm still tied to both Wi-Fi and security issues, I was going to dissect Brian Krebs' initial post "covering" a MacBook Wi-Fi "exploit" and the rather pathetic follow-up, but John Gruber beat me to it in his usual incisive style, so I'll go straight to the gory technical details and leave the questions for later.

My initial thoughts from watching the video were:

1. This was timed to lead up on the WWDC next week - even if they're not using the MacBook's built-in Wi-Fi (and why the hell aren't they? It would be much more impressive), they're riding the hype.
2. The demo was unnecessarily cheesy. Last year's Cisco exploits (which were a whole lot more serious) were far more professionally presented.
3. The article stumbled through the issues involved, making a jumble of things (signed drivers? ha!) and missing the basic questions.
4. The technique looks (despite their claims) like a pretty bog-standard buffer overflow + shell access exploit.

The twist here is that, if the code injection is done entirely through the Wi-Fi driver, that means the driver itself or the Wi-Fi card firmware used in that demo (which, remember, are not Apple's) should never have made it past QA.

Anywhere. The developer for that driver (or the firmware) ought to be fired, and the manufacturer of that USB dongle really should get their act together.

The reason the demo is so "impressive" (not my words) is that, unlike Windows, UNIX-based operating systems make it somewhat easier to gain useful remote access when you manage to do a buffer overflow - you set up a TCP socket, fork a shell, and you're in.

It actually just takes a few bytes, and there is no shortage of Intel-based exploits around - adding Mac OS X to the mix simply means you have to learn a new way to create a socket back to the attacker and invoke system('/bin/bash') or whatever by twiddling the stack and EIP.

If the hacker is someone who understands PowerPC assembly, the technique is pretty much the same (the code you send over doesn't have to run on the controlling machine), so the myth that PowerPCs are immune to this kind of thing is, well... a myth, fostered by the hacker community's single-minded focus on Intel CPUs and more than a bit of ignorance.

See, there's a nice bonus that comes with switching to Intel...

The days when people bothered to learn SPARC and Motorola assembly language are long gone - and the CPU monoculture only makes it easier to do this sort of thing.

But I digress. Once you manage to inject the right bytes, well... If you start out from a driver's executable context, chances are you're either root or some other entity able to do whatever you want.

The demo does seem to create a shell on the current user's home, but that gives absolutely no clue as to what the actual privilege level is (especially if the machine has only one user account - they could have just invoked a shell for the first user's home directory).

In Windows (provided you manage to avoid crashing the entire OS with the injected code), it takes a bit more work, but it's not unheard of for exploits to send over "precursor" code that then downloads and runs a complete executable (a lot of IRC 'bots did exactly that).

How they manage to inject enough code to do that through the Wi-Fi stack is a mystery as yet, but I have very serious doubts as to whether this is really a generic hack.

For starters (and reiterating the point above), the shell code has to be OS-specific, but it's extremely likely that the exploit code itself has to be finely tuned to the card + driver combination in question.

The Wi-Fi Menagerie

You see, there are far more variations of Wi-Fi card firmware than most people would suspect. Anyone who tested more than a dozen Wi-Fi cards - and I've tested a lot more, in several operating systems - can readily attest that it is not at all unusual to have virtually identical cards (obtained in separate weeks, from different production batches) carrying different firmware revisions, and behaving in completely different ways (and that's just considering "normal" behavior).

Then comes the driver itself, and that I find more susceptible to attack. Why? Well, you see, the card firmware used to limit itself to managing radio frequencies, encoding, etc, and very often some layer 2 functions ("raw" 802.11/Ethernet framing, encryption, CRCs, etc.).

Very seldom, some of these functions are hard-coded in silicon. The thing is, as soon as Wi-Fi began to mutate, that started to seem like a very costly approach. Consider what happened when WEP (which was performed entirely in hardware in some early card designs, with 64 and 128-bit silicon variants) turned out to be a dud.

So these days, as the industry moves to software-controlled radios, the functional split between driver and firmware isn't all that clear. Basically, the host CPU is doing more brunt work, a sad tendency that Intel has somewhat exacerbated with their overall designs - and shrewd watchers have noticed that Intel issued a bunch of firmware updates overnight...

On one hand, this casts further doubt over the general applicability of this exploit (since the driver layer is also under constant revision, as can be made plainly clear by perusing, say, Toshiba support downloads, which very often list several driver versions for the same chipset in the same laptops).

This means even finer tuning of the exploit code, since even if you keep a table of MAC addresses to figure out the manufacturer and likely firmware revision from what you see in the air, there is absolutely no way an attacker can know the driver version in use from "outside" - so their claim of being able to recognize 13 different wireless device drivers is, well, just a claim (or, most likely, Brian Krebs doesn't know the difference between recognizing a wireless device driver and recognizing a wireless device).

They can sniff out the OS fairly easily (any machine these days generates enough traffic to do so, even if not checking Windows Update every day), but I'm pretty skeptical about their being able to recognize the driver version with any sort of real accuracy.

Still, there is something here of interest. The software-oriented way does make it more feasible to inject executable code via some form of layer 2 framing attack - especially if the firmware is almost completely engrossed in doing only pure radio management and just tosses anything looking like a frame to the driver's executable context.

And, as the whole of the IT and Networking industry has demonstrated time and again in more or less spectacular foul-ups, programmers are lazy - especially when it comes to error checking. Doubly so those who work in embedded systems, firmware and drivers, where error checking is often skipped for performance (or pure time-to-market) reasons.

So yes, manufacturers should step up their QA testing and learn a thing or two about bounds checking as a result of this.

Anyway, the way the demo was done is a bit cheesy, to say the least.

For instance, the "password" file used as an example was a very cheap trick. The reality is that even if you log in as root, chances of being able to decrypt data are pretty much nil, so the "password" wasn't secret at all - it was just plain text, and in my mind one of the worst possible examples to use. I bet they called the file "password" just because it would look impressive, but it doesn't take much to see it's a gimmick.

Just like the "look, ma, no wires" bit. It was just for show, and completely unnecessary.

Furthermore, the timing itself is suspect. Using a Mac seems like an attempt at raising visibility of the technique by riding the tsunami of WWDC hype that seems to have taken over every single technical publication. If you publish anything even remotely related to Apple, you're certain of getting lots of attention.

Then comes the reporting. Oh, sorry, the "reporting". Although Brian Krebs does outline the real reasons why this sort of thing is occasionally possible, he fails to ask three important questions that would have crossed my mind instantly if I were there:

1. Is this really a generic, works-on-all-cards exploit?
2. Does this work out-of-the box (i.e., on a default configuration)?
3. Can you do that to my laptop?

Gruber asks a lot more questions that I can be bothered to do, and completely shreds the follow-up piece as well.

What completely damns Brian Krebs's reporting in my eyes is his statement -

I stand by my own reporting, as according to Maynor and Ellch it remains a fact that the default Macbook drivers are indeed exploitable.

He hasn't bothered to verify with his own eyes, really. And the conspiracy theory bits are, well... Cheesy.

The main points to retain from this are:

1. The CPU monoculture we're living in means every OS running atop Intel chips can be targeted in mostly the same way, regardless of the entry points.
2. The demo was not made with the MacBook's internal Wi-Fi card, and the reasons Brian Krebs published to explain that don't hold water. If the MacBook's built-in Wi-Fi is vulnerable, the demo would be a lot more credible.
3. The WWDC is next Monday. Using a Mac for this was like running through a bullring wearing a red raincoat - with their company logo emblazoned on the back. Talk about creative advertising.
4. Until the exploit technique is made public, there is no way to assess exactly how "generic" this really is, so they can claim whatever they want.

While it's true that a lot of device drivers are rushed to market without any sort of decent code review, stress testing and (most especially) vulnerability checking, I wouldn't worry just yet.

I would worry, however, if there turn out to be more than three hardware vendors affected by this. The hardware bits are the toughest to replace, even if things are most likely to be easily fixable with decent firmware and a driver upgrade or two.

Incidentally, signed drivers (such as those certified by Microsoft WHQL testing) are just as susceptible to this kind of thing as unsigned drivers - the testing they do does not cover this sort of vulnerability, focusing instead in interoperability with other drivers inside the operating system. All in all, it's a bit like making sure the driver's uniform matches your car upholstery without checking what he's been drinking.

Finally, people should keep in mind that Wi-Fi security has always been flaky - something that was never addressed properly from the outset, with vendors choosing to go for fancy encryption schemes that helped generate software/licensing/services revenue.

But if device driver writers (either for Wi-Fi cards or anything else) aren't doing bounds checks properly, then there's no point in their being in that business - they're better off switching to developing Enterprise JavaBeans or something.