centrino bug, (DD cross post)

[johnycsh at gmail.com (johnny cache)]

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.