Re: This guy cracks me up.

["johnny cache" <johnycsh () gmail com>]

I had a long response to this all typed up, but basically
it can be summarized as follows.

This Centrino bug is the only one currently patched. Nobody ever heard
me talk about it before there was a patch out, and now I'm providing details.
As more patches come out (including Apple's) we will release more details.
Out of respect for secureworks intellectual property, I don't feel comfortable
commenting on the apple situation any more than I already have. If you think
that's frustrating, let's just say it's not exactly the situation I had hoped
for either.


> >   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)
>
> I don't understand what this means. Does it mean that the victim
> computer *must* be running a netcat udp listener for the attack to
> work? If so, how would this be exploited in the wild?

No, in theory no open TCP/UDP ports should be required. Your wireless device
driver has no idea what layer 4 ports are open and it should be treating all
data packets the same at this point.  My guess is that having an open port
influences the delicate timing I described earlier.

A netcat listener is not required. UDP was chosen because it has a smaller
header.  It also takes less code to process, and therefore might result in more
deterministic timing relative to TCP. At the end of the day, there is nothing
special about netcat.  A single listening port should suffice. Using netcat
just makes it easier to verify that your packets are making it through the
layer2 device driver (you can see them print out).

If you were to implement this using a patched kernel, or found some other way
to inject packets at a faster rate, I suspect no open ports would be required.
Hard to say for sure though.

> >   3) start flooding the victim machine with disassociation
> >  requests. A BSOD should follow very shortly.
>
> So this attack crashes the machine?

Yes, in the event that the exploit does not succeed it will crash the machine.
However, it if does succeed, then remote code execution is possible.
The previous
posting illustrates how this is possible by showing that EIP is controllable.
For those versed in the security field, this is enough evidence to show that
exploitation is possible.

> >   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.
>
> Who needs two cards -- the victim or the attacker?

The attacker.  He needs to win a race condition that (with a stock kernel)
he seemingly can't.  This is why two cards were used -- to more easily trigger
the race condition.

> How exactly did she smear you? Why is that you feel free to say
> that you've been smeared, but won't state how you've been smeared?

> Even if you've been threatened, legally, by Apple, and thus feel
> you can't or shouldn't reveal any technical details regarding what

> you have found, why not at least state specifically the nature of
> the legal threat(s) against you?

The only response I have to this is the one I iterated before. Secureworks
doesn't want to release details about anything until this is all settled.
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave