RE: [Full-disclosure] Firewire Attack on Windows Vista
I made a short reply to this yesterday, but it probably came off as
flippant and thus didn't get posted. However, if one insists on leaving
their machine unattended in a public place, but have at least locked it,
but are still worried that someone will use a hardware-based firewire
attack, then just disable the host controller in the first place and be
done with it. Or, if one is already using a firewire device, but has
walked away and left their laptop alone in a public place along with
that firewire device on and activated and are worried about someone
coming along and plugging in their own in order to grab your Bitlocker
key, then don't have autorun (which is default) automatically enabled
for the device.
Of course that won't stop someone of opening up the laptop with their
handy-dandy Leatherman and using canned air turned upside down to
"freeze" the memory chip, take it out, put it in their laptop, search
for the key in memory, and then put it back in the other box to then
steal the data.
But more to Mr. Grimes original point, I actually don't mind seeing this
put as a "Vista" attack, be it "unpatched," or an attack against the
activation mechanism, or whatever. If the "Vista Firewire" attack is
what it takes for people to get into the news about Vista
"vulnerabilities," then I consider that a good thing.
t
> -----Original Message-----
> From: Tim [mailto:tim-security@xxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, March 06, 2008 12:00 PM
> To: Larry Seltzer
> Cc: Full Disclosure; Bugtraq
> Subject: Re: [Full-disclosure] Firewire Attack on Windows Vista
>
> > What are the implications for firewire device compatibility of doing
> > this?
>
> I am no expert on ieee1394, but I have read up a bit on this and
tested
> Metlstorm's memory dumping tool and here's what I understand:
>
> Firewire chipsets allow drivers to configure a particular memory range
> which is open to access by DMA devices. Since the memory transfers
> occur completely without software intervention, the only way to
> restrict
> this is to tell the chip ahead of time what to allow and what not to
> allow. Before these tools came out, most free OSes simply opened up
> access completely to physical memory for any device. However, Windows
> would not do this. It would only open up access to devices that it
> thought needed DMA. This is why Metlstorm had to make his Linux
machine
> behave like an iPod to fool Windows into spreading it's legs.
>
> Since the exploit tools came out for this, free OSes quickly started
> providing options to tell the chips not to open up access. I have
> tested the Linux drivers with the phys_dma=0 option, and found that
> some
> disk devices worked fine while others did not. I can confirm that the
> memory dumping tools did not work with this option set.
>
> Of course this is not an optimal fix. The drivers should just
> automatically restrict the DMA accesses in real time to a range that
is
> safe but still permits devices to use it. (Presumably to buffers
> allocated specifically for I/O.) Not sure if some devices would still
> have problems with this, but I think this is the intended operation of
> ieee1394 based on the specs and I'd imagine it would work on a greater
> number of devices than having it disabled completely.
>
> Someone please correct me if I'm wrong on any of this.
>
> tim