Hi Maxim. I did not completely power off the system when I tried the test.
I did a warm reset and booted to a USB drive.
I'm not sure about the inconsistency with the debugging-via-ohci1394 docs.
There are two alternative driver stacks (e.g. ieee1394 and firewire-core)
and the docs talk about them both interchangeably. It's a bit confusing.
The CONFIG_FIREWIRE_OHCI_REMOTE_DMA kernel hacking option may only be
relevant to the legacy ohci1394 module.
One thought is that it the sbp2 module might be allowed to circumvent
whatever filtering is happening. Sbp2 enables full DMA access, and I
haven't been able to carry out Firewire DMA attacks via Inception without
it. This message talks about sbp2 having physical DMA, yet being filtered:
http://lkml.indiana.edu/hypermail/linux/kernel/0802.1/0347.html . The
message he's responding to says the new modules make it "a bit harder to
use physical DMA, but not impossible".
Regardless, a fix is to blacklist these modules from loading automatically.
Then users can still opt in to enable Firewire if they need it, but it's
not vulnerable by default. You could add the following lines to
/etc/modprobe.d/blacklist.conf:
"""
blacklist firewire_core
blacklist firewire_ohci
blacklist firewire_sbp2
"""
Or just disable Firewire in the kernel by disabling CONFIG_FIREWIRE.
On Sun, Oct 14, 2012 at 5:03 AM, Maxim Kammerer <mk@???> wrote:
> On Sat, Oct 13, 2012 at 5:18 AM, Maxim Kammerer <mk@???> wrote:
> > On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis <steveweis@???> wrote:
> >> I think the kernel is working as expected. Debian and Ubuntu are both
> also
> >> vulnerable by default, since FireWire modules are loaded automatically.
> >
> > From Documentation/debugging-via-ohci1394.txt:
> > “The alternative firewire-ohci driver in drivers/firewire uses filtered
> physical
> > DMA by default, which is more secure but not suitable for remote
> debugging.”
>
> There is some more information in 1394 OHCI Spec v1.1 [1, §5.14.2].
> drivers/firewire/ohci.c doesn't touch OHCI1394_PhyReqFilter* registers
> at all if CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set, so physical
> request DMA should be forwarded to asynchronous request DMA. Could it
> be that the kernel does not implement AR DMA correctly?
>
> There is also something strange when the spec is compared to the older
> v1.0 spec [2, §5.13.2]. The older spec does not have a clarification
> wrt. what happens on a bus reset, in Table 5-21 (whether it has such a
> clarification in §5.13.1, for instance). It has such a clarification
> in the newer v1.1 spec, in Table 5-22. Is it possible that when
> implementing OHCI 1.0, vendors did not know what to do, and kept the
> physReq* registers values even over a soft reset? This is quite
> unlikely, of course, but did you try to power off the computer
> completely before performing the test?
>
> [1]
> http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf
> [2] ftp://ftp.microsoft.com/bussys/1394/OHCI/Released_Specs/OHC1.0.pdf
>
> --
> Maxim Kammerer
> Liberté Linux: http://dee.su/liberte
>
