Metasploit mailing list archives
centrino bug, (DD cross post)
From: johnycsh at gmail.com (johnny cache)
Date: Sun, 3 Sep 2006 16:06:16 -0700
Hi, a friend suggested i send this out here as well. Since there are a lot less trolls here I think its a good idea. I intentionally left out the names of people who helped me on this since being associated with me in pubilc is probably not a good career move. Anyone who knows me knows me can guess who helped me, and if anyone feels short-changed for not being mentioned I'm sorrry I made the wrong choice. Once this is all cleared up I will be glad to give everyone credit. <begin DD cross post referring to the daring fireballs challenge> ---------- From: MindsX <mindsx at gmail.com> Subject: Re: [Dailydave] This guy cracks me up. They may not take up the challenge - however - it will be much easier to dismiss if there is no public backing... Considering this is IMHO the equivalent of Milli Vanilli with laptops... It really should be discouraged that anyone in the industry should make people feel insecure via distortion of the media with vaporware Too many of these idiots will not do any favors to the sector - nor to the reputations of those in it. -------------------------------
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' makes 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.
Current thread:
- centrino bug, (DD cross post) johnny cache (Sep 03)