Slashdot Mirror
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."
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."
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.
I still don't see any proof that Apple's lawyers have done anything.
I can imply very loudly that Microsoft has been threatening me for years, but that doesn't mean they even know I exist.
"- 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.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
They keep stating Apple is pressuring them, but Apple says they have not contacted Apple with any info.
They state they won't say anything until Apple patches the problem? It would speed up the process of getting it patched if they would tell Apple about it!
From what I can tell, they are pretending Apple is pressuring them because it makes them look more important.
Addtional note, what is this stuff about Intel's drivers? Apple doesn't use Intel's chipset, they use an Atheros or Broadcam WiFi chipset. Additionally, what good is getting your packet on the stack? Apple uses the NX bit, so you can't get code on the stack to execute.
http://lkml.org/lkml/2005/8/20/95
Hint to everyone: OSes do weird things
Hint to everyone: RTFA for yourself and ignore uninformed slashdot comments masquerading as authoritative ones.
as install two wireless cards
He speculates that triggering the race condition with a single NIC is possible, two NICs makes it easier. He was just telling the community what he found, and that steps should be taken by the vendors to fix it (and they did, if you read his message). Just because he couldn't trigger it with a single NIC, doesn't mean 1) We should ignore the issue 2) someone else can't
and a netcat listener.
The exploit would work on a machine that has any sort of UDP listener running on the interface being attacked. Netcat is merely useful for demonstration purposes, otherwise we'd have people concerned that e.g. a bug in Skype (if that UDP service was targeted instead) is the real vector for the exploit rather than the Intel NIC driver.
I'm sure Apple will fix it asap.
And if you had read his message, you'd see that 1) Apple has patched it already, 2) it's an Intel bug, not Apple's.
I work in the IT security industry and I'm perfectly willing to accept that this exploit is for real. The pattern of events is not abnormal: the exploit will be demonstrated at a conference but because of NDA the details remain under wraps until the manufacturer releases a patch.
I am a mac user and work in security as well. Let me show the ways in which this "exploit" is unusual and dubious:
I used to work with this guy who was brilliant at finding and exploiting security holes. He took a G3 Mac running stock standard OSX and proceeded to demonstrate exploit after exploit; not based on his OSX skill but purely on his knowledge of the underlying free software.
There are a number of people who can easily find local escalations on OS X, using knowledge of the BSDs. There are some people who can remotely hack OS X boxes using unpublished exploits. OS X is not some super-secure solution. It is in the same boat as your average Linux distro. It is fairly secure against automated attacks which is what the average user is worried about.
I was at a blackhat conference where they demonstrated a local privilege escalation exploit that existed all the way up to Tiger - they had told Apple about it years previously but it wasn't until they broke their NDA and went public that Apple fixed the fault. The same presentation at that conference demonstrated an OSX kernel exploit that still exists today.
Citations please.
Mac users are in for a rude shock. They've told each other their platform is secure.
Secure means different things to different people. By comparison to Windows, which is all the average user knows, OS X is a fortress. The message that "OS X is secure" is a drastic oversimplification, but it is a clear message and a beneficial one. The more users that switch away from the security nightmare that is Windows, the better for the security of the general population. Now you could try to tell the average person that OS X is sorta secure, but not perfect and it is better than Windows but worse than this OpenBSD thing that can't run any mainstream software they need. In doing so you'd be more accurate. You'd also probably convince a lot of people that it doesn't matter if they are running OS X or Windows and thus contribute to making the general population less secure.
As for this particular exploit, the verdict is still out. Maybe it is the real deal that has a reasonable chance of being a usable remote exploit. To characterize this as a normal vulnerability, is very misleading. There is a reasonable concern in the security industry that these people either were wrong, overstated their case, or were outright trying to be deceptive. There is also the possibility that Apple is completely lying, but that is rather unlikely. They have a pretty good track record of fixing exploitable vulnerabilities the community brings to them and of working well with the security community. They are one of the few companies that provides credit for discovery in their security patches. As time goes on and we learn more and more about this, I have more and more doubts that this particular exploit is on the level.