IEEE 1394 (FireWire) Memory Imaging

[Tim-10]

Hello,

I recently came across a fantastic (and alarming) tool kit for reading
systems' memory over firewire:
  http://www.storm.net.nz/projects/16

I just used it to dump memory off of my laptop while booted to both
Windows XP and Linux.  I'm kinda surprised that this vulnerability
hasn't been addressed in these OSes, since it has been known for some
time, but I guess it's more of a hardware problem.

In any case, I was wondering if anyone has used this technique to
capture physical memory in investigations.  It seems like it could be
quite elegant and minimally intrusive, if well tested.  If you have used
it, how did you account for the possibility of the suspect system
reading/writing your acquisition system's memory?  It seems it could go
both ways.  Secondly, have you had problems with specific OSes?
(Windows XP doesn't give up it's RAM, until you trick it into thinking
you're a mass storage device, then it works fine for me.)

thanks,
tim


PS- I appologize if this has been covered on the list in the past.
    Please direct me to appropriate threads if so.

[Valdis.Kletnieks]

On Thu, 22 Feb 2007 11:28:42 EST, Tim said:
> I recently came across a fantastic (and alarming) tool kit for reading
> systems' memory over firewire:
>   http://www.storm.net.nz/projects/16

The original demonstration was for a Mac - google for 'pwn a mac with your ipod'
and that should find it. ;)

There's also Firescope: ftp://ftp.firstfloor.org/pub/ak/firescope/
which has been used for debugging Linux kernels.

> I just used it to dump memory off of my laptop while booted to both
> Windows XP and Linux.  I'm kinda surprised that this vulnerability
> hasn't been addressed in these OSes, since it has been known for some
> time, but I guess it's more of a hardware problem.

Well, the problem is that Firewire allows for DMA control from the other
end of the wire.

For Linux, it's addressable by either:

1) Making sure there's no ieee1394 driver loaded by blacklisting it in
whatever udev/modules file your distro uses for such things.  No driver
loaded means the near end of the wire isn't initialized, so it doesn't work.

2) Force the module to be loaded with the parameter 'phys_dma=0'.
This causes the ieee1394 chipset to be initialized with settings that
reject the DMA requests.

> In any case, I was wondering if anyone has used this technique to
> capture physical memory in investigations.

I'm sure that if it's been used to hack Macs and debug Linux kernels,
somebody is using it for investigations. :)

[Monniez Christophe]

Le jeudi 22 février 2007 à 11:28 -0500, Tim a écrit :

> Hello,
>
> I recently came across a fantastic (and alarming) tool kit for reading
> systems' memory over firewire:
>   http://www.storm.net.nz/projects/16
>
> I just used it to dump memory off of my laptop while booted to both
> Windows XP and Linux.  I'm kinda surprised that this vulnerability
> hasn't been addressed in these OSes, since it has been known for some
> time, but I guess it's more of a hardware problem.
>
> In any case, I was wondering if anyone has used this technique to
> capture physical memory in investigations.  It seems like it could be
> quite elegant and minimally intrusive, if well tested.  If you have used
> it, how did you account for the possibility of the suspect system
> reading/writing your acquisition system's memory?  It seems it could go
> both ways.  Secondly, have you had problems with specific OSes?
> (Windows XP doesn't give up it's RAM, until you trick it into thinking
> you're a mass storage device, then it works fine for me.)
>
> thanks,
> tim
>
>
> PS- I appologize if this has been covered on the list in the past.
>     Please direct me to appropriate threads if so.

Hi,

I'm the maintainer of the FCCU GNU/Linux boot CD.
(www.lnx4n6.be).
We use this technique in investigation (thanks to Metlstorm for his
help) and the tools are on the latest version of our boot CD (version
11.0).

For using it, you need to have a mass storage device to acquire the ROM
from before using it (because I didn't provide a ROM on the boot CD to
avoid Copyright problems).

As far as I know, for win XP, a user have to be logged in first to have
windows recognizing the false mass storage device.

And if you want to do it again against the same computer, you have to
manually "uninstall" the device from the windows system (we saw that
during demonstration of this technique).

The next step (we are looking for that and MetlStorm too), is to find
the bytes in the ROM that tell Windows that this is mass storage device.
The idea is to make an "injector" without the need of ROM.

Metlstorm is also working on a better interface.



--
Christophe Monniez <d-fence@...>
www.d-fence.be - www.lnx4n6.be

[Tim-10]

Hello Valdis,

> The original demonstration was for a Mac - google for 'pwn a mac with your ipod'
> and that should find it. ;)
>
> There's also Firescope: ftp://ftp.firstfloor.org/pub/ak/firescope/
> which has been used for debugging Linux kernels.

Right, I heard about the original demonstration a while back, but hadn't
found a decent tool until recently.  I also looked at firescope, which
looks quite interesting, but obviously isn't quite the tool for my task.

> Well, the problem is that Firewire allows for DMA control from the other
> end of the wire.
>
> For Linux, it's addressable by either:
>
> 1) Making sure there's no ieee1394 driver loaded by blacklisting it in
> whatever udev/modules file your distro uses for such things.  No driver
> loaded means the near end of the wire isn't initialized, so it doesn't work.
>
> 2) Force the module to be loaded with the parameter 'phys_dma=0'.
> This causes the ieee1394 chipset to be initialized with settings that
> reject the DMA requests.

Right, I've tested this in various scenarios and it seems to work out.
The Linux kernel does not open up the physical request filters when
phys_dma=0.  However, do you know if there's anything interesting that
can be done if physical requests are denied, but the asynchronous
request filters are opened up?  I don't know quite enough about FireWire
yet to know that answer.

This article has some interesting tidbits:
  http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/

> I'm sure that if it's been used to hack Macs and debug Linux kernels,
> somebody is using it for investigations. :)

Well, what I am getting at, is has anyone tested the techniques well
enough to feel comfortable using it on an important investigation?  You
know, like one that could go to court.  I'm sure people are using it for
various fun things, and may even gumshoe sysadmins might be using it,
but is it stable enough yet to be forensiclly sound?

thanks,
tim

[Tim-10]

Hi Christophe,

> I'm the maintainer of the FCCU GNU/Linux boot CD.
> (www.lnx4n6.be).
> We use this technique in investigation (thanks to Metlstorm for his
> help) and the tools are on the latest version of our boot CD (version
> 11.0).

Yes, I just noticed that.  (Actually, Metlstorm mentioned it.)  

> For using it, you need to have a mass storage device to acquire the ROM
> from before using it (because I didn't provide a ROM on the boot CD to
> avoid Copyright problems).

I see.  I was wondering about the copyright issues...  I actually tried
yanking a ROM off of a different attached mass storage device and using
it instead, but I wasn't able to pull it down.

> As far as I know, for win XP, a user have to be logged in first to have
> windows recognizing the false mass storage device.

That's interesting.  I wonder if emmulating some other type of device,
which also requires DMA, will allow access when users aren't logged
in...

> And if you want to do it again against the same computer, you have to
> manually "uninstall" the device from the windows system (we saw that
> during demonstration of this technique).

That's also good to know.

> The next step (we are looking for that and MetlStorm too), is to find
> the bytes in the ROM that tell Windows that this is mass storage device.
> The idea is to make an "injector" without the need of ROM.
>
> Metlstorm is also working on a better interface.

Yes, that sounds like a good approach.  No need to emmulate a particular
storage device, if you know the right bits to twiddle.  Are there other
device types (video, audio, etc) which might also cause Windows to open
up those physical filters?


Perhaps more relevant to the forensics side of the discussion, do you
know much about the findings by GM Garner that certain portions of
Windows memory are not correctly read by this method?

thanks,
tim