bugtraq - Re: [Full-disclosure] 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]

Date: Sat, 8 Mar 2008 10:32:33 -0800
From: Tim <tim-security@...tinelchicken.org>
To: Larry Seltzer <Larry@...ryseltzer.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: [Full-disclosure] Firewire Attack on Windows Vista

Hi Larry,

> - use drive
> encryption, use 2-factor authentication, use hibernate instead of sleep,
> use group policy to enforce them.

Uh... yeah.  So how again does drive encryption help you against this
attack?  Certain forms of 2-factor auth might help you, but all of the
kinds I've seen would still rely on encryption keys in memory to encrypt
any sensitive data on the drive, not to mention the fact that writing to
memory would still bypass that auth.  The funniest is using hibernate...
Did you perchance read:
  http://www.eff.org/press/archives/2008/02/21-0
??

Once again MS treats a security issue as a PR issue.

> The fact that you can turn off DMA on Linux
> seems in fact inferior to simply disabling the Firewire port and driver
> at run-time in Windows. They both suck as solutions. 

How exactly is the Linux solution inferior?  Not just trying to defend
Linux and attack Windows here, but really I don't see how this statement
is true, so you must not understand how it works.  By disabling DMA,
you're just disabling it for that one driver, not all drivers.  In
addition, you can load/unload driver modules at run-time typically.

> Incidentally, Microsoft made a few other points in their response that
> were interesting, but raised more questions than they answered: 
> 
> * it's possible for a user to disable 1394 DMA. I'm still looking into
> how you can do this.

That would be interesting to find out.  Please do tell if you figure out
how this can be done.

> * it's possible for a user to "constrain a DMA device's memory access to
> specific ranges by using the physical DMA type." They say that some
> devices cannot be so restricted at all, and for others the restriction
> would only come at the cost of additional complexity and a performance
> hit, as I allude to above. I assume these considerations are generic to
> the hardware and not specific to Windows.

Ok, so they concede it is possible to limit the DMA accesses to specific
(safe) ranges.  I wonder which devices cannot be restricted...

> How much should the average user worry about this? Not very much.

Yeah, I agree it's probably not a big risk right now.  That may change
over time though, as more and more small devices become very
programmable.  You can already hack Linux onto your iPod, which makes a
great cover for casually compromizing machines in an office environment.
The number of small devices which would normally seem benign to end
users, but are capable of being quite evil, will only increas over time.

Good luck with your article,
tim