> So my theory is: they ran the demo against the built-in Apple wifi
> card!
>
> What do you think ?
Doesn't matter. As we all know, Apple doesn't actually manufacture
anything: all its parts including its 802.11 cards are supplied by
other manufacturers and the drivers for them are supplied by the
manufacturers. Apple's 802.11 cards are almost identical to those
used in Wintel machines and the driver software used for them are
almost identical too: the actual demo may have been done on Apple
drivers or not, but any vuln discovered will exist in all similar
drivers.
On 12 Aug 2006, at 10:12pm, Bill Weiss wrote:
> I talked to Johnny Cache at DefCon after his talk a bit. I hope that
> what I remember from that discussion can help here:
>
> * The exploit is running in kernel space and can do _anything_ it
> wants.
> It's not running as root because that would involve running
> under the
> kernel. In Intel terms, this is ring 0 stuff.
The vuln, if it exists (and I'm not disputing that) is in the
software the computer uses to talk to the driver. This software must
necessarily run at the same level as the OS itself (since the OS, at
its lowest level, depends on being able to use some of the facilities
provided by the driver). Therefore it's quite possible that a vuln
in an 802.11 driver would be a vuln at the lowest level of the OS.
This is why open source driver software, where thousands of eyes can
inspect the code for weaknesses, is important. An alternative would
be for the industry to change its model of supplying drivers: instead
of supplying a driver that works and saying 'use this one' it could
completely document the hardware and firmware it supplies and allow
people to write their own drivers. Do not expect this any time soon,
since by existing standards, completely documenting the hardware and
firmware would constitute giving away secret information about how
the device works.
> * Firewalls, "preferred networks" and other OS-level mitigation is
> worthless. The packets don't have to contain any IP data, they are
> pure 802.11{b|g} frames. The OS doesn't see the packet because it
> would have to get past the (exploited) device driver.
>
> * The exploit doesn't require associating to an AP, being
> associated to
> an AP, anything. It just requires the wireless device to be on.
Both of those depend on exactly where the vuln is. It might be at
the bare bytestream level, it might be at the TCP/IP level, it might
be at the 802.11 level. If the above two points are statements by
the guy who demonstrated the vuln, that suggests that the problem is
serious and cannot be defeated without disabling the 802.11 card.
Simon
--
Simon Slavin Fylde Building Room C11
Computing Development Officer 01524 65201 x 93569
Psychology Department
University of Lancaster
On 12 Aug 2006, at 8:02am, Nicolas RUFF wrote:
> So my theory is: they ran the demo against the built-in Apple wifi
> card!
>
> What do you think ?
Doesn't matter. As we all know, Apple doesn't actually manufacture
anything: all its parts including its 802.11 cards are supplied by
other manufacturers and the drivers for them are supplied by the
manufacturers. Apple's 802.11 cards are almost identical to those
used in Wintel machines and the driver software used for them are
almost identical too: the actual demo may have been done on Apple
drivers or not, but any vuln discovered will exist in all similar
drivers.
On 12 Aug 2006, at 10:12pm, Bill Weiss wrote:
> I talked to Johnny Cache at DefCon after his talk a bit. I hope that
> what I remember from that discussion can help here:
>
> * The exploit is running in kernel space and can do _anything_ it
> wants.
> It's not running as root because that would involve running
> under the
> kernel. In Intel terms, this is ring 0 stuff.
The vuln, if it exists (and I'm not disputing that) is in the
software the computer uses to talk to the driver. This software must
necessarily run at the same level as the OS itself (since the OS, at
its lowest level, depends on being able to use some of the facilities
provided by the driver). Therefore it's quite possible that a vuln
in an 802.11 driver would be a vuln at the lowest level of the OS.
This is why open source driver software, where thousands of eyes can
inspect the code for weaknesses, is important. An alternative would
be for the industry to change its model of supplying drivers: instead
of supplying a driver that works and saying 'use this one' it could
completely document the hardware and firmware it supplies and allow
people to write their own drivers. Do not expect this any time soon,
since by existing standards, completely documenting the hardware and
firmware would constitute giving away secret information about how
the device works.
> * Firewalls, "preferred networks" and other OS-level mitigation is
> worthless. The packets don't have to contain any IP data, they are
> pure 802.11{b|g} frames. The OS doesn't see the packet because it
> would have to get past the (exploited) device driver.
>
> * The exploit doesn't require associating to an AP, being
> associated to
> an AP, anything. It just requires the wireless device to be on.
Both of those depend on exactly where the vuln is. It might be at
the bare bytestream level, it might be at the TCP/IP level, it might
be at the 802.11 level. If the above two points are statements by
the guy who demonstrated the vuln, that suggests that the problem is
serious and cannot be defeated without disabling the 802.11 card.
Simon
--
Simon Slavin Fylde Building Room C11
Computing Development Officer 01524 65201 x 93569
Psychology Department
University of Lancaster
[ reply ]