Q: Do you have to using Kismet or the Airport utility to be compromised by this?

HD: This particular exploit only seems to trigger when the card is in active scanning mode. I was able to trigger a similar bug when the card is in "idle" (non-associated) state, but I need more time to investigate it before I can give you more information.

Q: Can this exploit code be used to seize remote control over a fully patched Mac 10.8 machine?

HD: This exploit can be used to demonstrate a memory overwrite using attacker-controlled data. With a little more work, this can be used to develop a functional remote exploit for a fully patched 10.4.8 system that uses the affected driver.

Q: Are there any mitigating circumstances that might lessen the severity of this vulnerability for a Mac user?

HD: Due to the nature of the bug, exploitation is going to be somewhat unreliable. Most of the time, the fatal exception occurs in the Airport driver, but I have seen the ATA driver and the ATI video card driver trigger the kernel panic instead. It all depends on what internal structures are overwritten and what driver happens to use those structures. This is similar to a standard heap overflow, except that an overflow in one driver can lead to a completely different driver crashing (since they share the same memory pool). It may be possible to make this exploit reliable by hammering the Airport driver with requests while triggering the bug.

Q: When did you find this bug?

HD: Saturday night.

Q: Have you reported it to Apple? If so, what was their response?

HD: I have not reported it to Apple, but I have given a friend of mine at Apple a "heads up" and provided him with a stack trace and some fuzzing tools. He was able to reproduce one of the flaws I found, but not this one in particular. So far, we are assuming that the hardware difference between our test platforms is the reason he can't reproduce it.

Q: Do you have any evidence that Apple tried to fix this particular problem before in a previous patch?

HD: Nope.