Re: This guy cracks me up. (MindsX)

[Lyndon Sutherland <lyndons () paradise net nz>]

Hey there,

I am curious about winning the race, where you mention the beacon packet 
of another AP within proximity ending up on the stack. Wouldn't this 
race be difficult to win in a real life environment where there is even 
moderate numbers of wireless networks or APs and activity? Or, am I 
missing something?

Secondly, I am curious, but without the listener on the victim machine, 
how much would this reduce the likelihood of the attack working?

Cheers
L

johnny cache wrote:
> > Considering this is IMHO the equivalent of Milli Vanilli with laptops...
>
>     Hahah, I'll add that to my ever-growing list of cheap personal attacks.
>     As everyone has noticed by now, we haven't said anything in public about
>     this attack yet. There are two reasons.
>
>     1) 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.
>
>     2) Responding to mac bloggers isn't my idea of a good time. Nothing
>        I could say would ever convince them. This isn't even a personal
>        attack against them; it's that they lack the technical skills required
>        to understand this problem. In short, anyone qualified to sit and
>        discuss the look and feel of changes of Mail.app probably has no idea
>        what ring0 code execution means. This is blatantly evident across
>        all these mac blogs. Here are a few glaring examples:
>
>
>       -InMuscatine (a daringfireball supporter)
>       http://inmuscatine.com/?p=524
>       "I know what you *think* you saw, but let me ask you this : did
>       they let you pick out your own strong alphanumeric password to
>       enter into the MacBook for them?"
>       -Because we all know that shellcode is required to double check
>       that it knows the root password after it has acquired EIP but
>       before it does anything else. Right?
>       
>       -TheTaoOfMac
>       http://the.taoofmac.com/space/blog/2006-08-03*
>       "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."
>
>       Chances are you're root? Running in the kernel...
>       
>       I could go on, but like I said, I've got better things to do than
>       reply to mac bloggers. 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.
>
>       For starters, here are links to two crash dumps-- one is a failed attempt
>       to get EIP on the vulnerable centrino driver, and one shows
>       successful control of EIP. The failed attempt is included because it is a lot
>       easier to tell where the box crashed (inside the intel driver), than
> it is for the
>       successful one.
>
>       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.
>
>       So how does it work?
>       There is a race condition inside the centrino driver. Unlike most
> straightforward
>       ring0 exploits out there, this one is intimately related to timing. I
> also never bothered
>       to reverse the driver because it seemed so unlikely that I would
> actually figure out the
>       cause of the bug that it wasn't worth it. Instead I just took a black
> box approach. After many
>       hours of staring at packet dumps I came to the conclusion that the
> bug wasn't related to   specific
>       
> bytes/ordering of the packets, but the relative times. Triggering the
> race condition is fairly
>       easy.   
>       
>       1) set up a netcat udp listener on the victim centrino box. (Why you
> actually need a listener
>          is beyond me, but it seems to help)
>
>
>
>       2) start blasting udp packets at it from a machine. sleeping for
> about 4000 microseconds
> between packets seems to be a good start.
>
>
>
>       3) start flooding the victim machine with disassociation requests. A
> BSOD should follow
>
>       very shortly. A delay of 5000 microseconds between packets seems useful.
>
>       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, the UDP packet was 1400 bytes.
>       
>       The reason this bug takes two cards to exploit is that the race
> condition you are trying
>       to win seems to be so small that a single card can't win it.
>       Every attempt to trigger the race condition by sending disassociate
> packets, followed up
>       by a flood of data packets out of the same card failed to land a data
> packet on the stack.
>       This does not mean that the bug cant reliably be exploited. I suspect
> that a linux box patched
>       with the appropriate real time patches required could hit this like
> clockwork. In the most
>       extreme case one could put the exploit into kernel-land itself.
>
>
> > It really should be discouraged that anyone in the industry should make
> > people feel insecure via distortion of the media with vaporware
>
>
> 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?
>
> > Too many of these idiots will not do any favors to the sector - nor to the
> > reputations of those in it.
>
>     If Apple's smear campaign has spilled over and done you some
>     personal harm, I'm sorry to hear it.
>
> -jc
>
>
> --Crash2: Unsuccessufly attempt to gain EIP, shows what is going on however.
>       http://www.802.11mercenary.net/~johnycsh/prone_to_deletion/dd/crash2-windbg.txt
>       http://www.802.11mercenary.net/~johnycsh/prone_to_deletion/dd/crash2.zip
>
> --Crash3-- Successful control of EIP.
>       http://www.802.11mercenary.net/~johnycsh/prone_to_deletion/dd/crash3-windbg.txt
>       http://www.802.11mercenary.net/~johnycsh/prone_to_deletion/dd/crash3.zip
>
>
> *Rui deserves some credit here because he is the only mac blogger who
> was actually
> genuinely interested in learning how this worked enough to email us
> and read a copy of the slides.
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave