[Dailydave] This guy cracks me up. (MindsX)

[Lyndon Sutherland]

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 at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
> 
>