Johnny Cache Breaks Silence On Wi-Fi Exploit

Joe Barr writes, "Johnny Cache — aka Jon Ellch — is chafing under the cone of silence placed over him and co-presenter Dave Maynor about the Wi-Fi exploit they presented at Black Hat and DEFCON last month. So he has finally broken his silence on NewsForge in hopes of ending the personal attacks coming from what he implies is a smear campaign started by Apple." (Newsforge and Slashdot are both owned by OSTG.)

Johhny Cache writes, "If you're going to post a news story that is a rehash of my post to a mailing list, I would much prefer it if people actaully just read the post in its entirety."

Comments

Article text

[Anonymous Coward]

Johnny Cache breaks silence on Apple Wi-Fi exploit

Monday September 04, 2006 (01:07 PM GMT)

By: Joe Barr

Jon Ellch -- aka Johnny Cache -- was one of the presenters of the now infamous "faux disclosure" at Black Hat and DEFCON last month. Ellch and co-presenter Dave Maynor have gone silent since then, fueling speculation that the entire presentation may have been a hoax. Ellch finally broke the silence in an email to the Daily Dave security mailing list over the weekend, and one thing is clear: he is chafing under the cone of silence which has been placed over the two of them.

Ellch explains their silence since the presentations in his email by saying:

        Secureworks absolutely insists on being exceedingly responsible and doesn't want to release any details about anything until Apple issues a patch. Whether or not this position was taken after a special ops team of lawyers parachuted in out of a black helicopter is up for speculation.

He also went on to explain that while the debate was centered in the Mac blogger community, it made no sense to discuss it because most of them wouldn't understand the explanation if he gave it, adding, "Since this conversation has moved into a venue of people who can actually grasp the details of this, I'm ready to start saying something."

Ellch then breaks down the elements of the vulnerability and possible exploits, but in the context of Intel drivers rather than Apple's, asking and then answering the obvious question of why he did so when he wrote: "Why am I switching the subject from Apple's bug to Intel's? Because it's patched, and Secureworks has no influence over what I say regarding this one."

He buttressed his explanation of how he crashed the Intel Centrino driver by creating a race condition by flooding it with UDP packets and disassociation requests with links to dumps of crashes he caused using this technique.

Ellch notes that a crash caused this way doesn't guarantee a successful exploit, saying "If you're lucky, your UDP packet will end up on the stack. If you're less lucky, a beacon packet from a nearby network will end up on the stack. In the case where I successfully overwrote eip (Extended Instruction Pointer), the UDP packet was 1400 bytes."

He also responded to criticisms that he and Maynor have simply been "playing the media" instead of reporting an actual vulnerability and exploit, saying:

        You know, of all the comments I see, the ones that 'we played the media' make the least sense. Have you ever seen me in the news before? No. Have I ever talked to a reporter before? No. Am I doing a very good job of winning this PR smear campaign lynn fox ignited? No. If I was so deft at manipulating the media, would I be explaining myself on dailydave praying that a few technically competent people will actually get it?

I contacted Ellch by email after reading his post and asked if he was claiming Apple is the cause of their silence. He replied:

        Let's just say its pretty obvious I'm not happy about being silent. So much so that i'm releasing non-apple bugs to convince people that we do in fact know what we're talking about.

Re:Honestly weird

[Inoshiro]

"- how can a driver have the same bug on windows and macos x?"

Quite simply; the Intel card is, in both cases, doing things like UDP and TCP offload from the main system. This means the card and driver together have an internal state in software to manage it, and (due to the asynchronus nature of networking) you can get the hardware and driver software's core into a situation where they don't agree on the state.

The small glue layer that deals with the OS hooks is a static translation layer that wouldn't be involved. The SB Live! and Audigy drivers in Linux are the same driver as the Windows Creative driver (well, they were about 6 years ago when they contributed the code). nVidia uses the same driver code on all platforms as well. For anyone who's written a driver, this is easy to understand.

"- why use this stupid external card? what are the chances it did have the same chipset as the internal one?"

He uses it because it's a timing race, and because it's easier to demonstrate with 2 cards in the system. With a 4000 microsecond delay, this means it's likely taking a bit longer for the OS to service the interrupts between the two cards; enough that the driver bug can show itself. There are likely other ways to tickle this bug that don't require multiple cards, but then you'd have to have something running on the OS. Still, If you setup a machine to throw packets around, you could make an intermittent crash bug appear on an OS -- that's not cool.

"- and odds are the bug is a buffer overrun... does it take a SO LONG for apple to fix a stupid memory overrun?"

A stupid memory overrun? Man, you haven't programmed ever, have you? A timing related bug in device driver code is probably the second hardest bug you'll ever encounter to debug (the first would be the core of the OS itself). Concurrent programming is difficult.

It's responses like these that show why this person had been light on detail. Most people lack the technical background in OS design to understand this issue.