On 8/11/06, Todd Woodward <todd_woodward (at) symantec (dot) com [email concealed]> wrote:
> "Another point of consideration is the level of access afforded by this
> hack. In the video demonstration, the hostile Dell machine was able to
> access user-level functions only. There was no indication as to whether
> any admin or root-user level tasks could be accomplished," MacFixIt
> reports.
> MacFixIt explains, "This will cause your portable to connect only to
> trusted networks, refraining from automatically joining networks without
> user permission."

First, one should assume that root-level tasks are likely, because the
exploited software is running in the context of the *kernel*. Just
because they moved some files around doesn't imply that other tasks
aren't possible. If someone has an Apple document describing how
device drivers don't operate in kernel space, I'd really like to read
it. I don't see how the shell could be anything other than root.

Also, I'm not convinced the above fix would help anything at all. The
exploit lives in the device driver and happens as the driver reads the
packet. As far as I know, those "preferred networks" live in higher
layers (I'll let you know when I get to this part in OS X Internals).
How can they decide to drop packets based on AP identification without
first passing that packet through the driver? The device would have
already been exploited just by reading the packet! What network
you're on, in theory, has nothing to do with it.

I wouldn't trust any source claiming to mitigate this threat without
knowing that they've tested it against the original proof of
concept... everything else is just theoretical.

--
Sam Pierson

[ reply ]