full-disclosure - Re: Firewire Attack on Windows Vista

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080306200009.GB5138@sentinelchicken.org>
Date: Thu, 6 Mar 2008 12:00:09 -0800
From: Tim <tim-security@...tinelchicken.org>
To: Larry Seltzer <Larry@...ryseltzer.com>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>,
	Bugtraq <bugtraq@...urityfocus.com>
Subject: Re: 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/