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-next>] [day] [month] [year] [list]
Date: Sat, 8 Mar 2008 07:12:32 -0500
From: "Larry Seltzer" <Larry@...ryseltzer.com>
To: "Bryon Roche" <kain@...n.org>,
	<full-disclosure@...ts.grok.org.uk>
Cc: <bugtraq@...urityfocus.com>
Subject: RE: [Full-disclosure] Firewire Attack on Windows Vista

>>What points are you trying to stab at for an article? 

You've hit on them pretty well. My own experience with DMA programming
was 20 years ago with real mode DOS drivers, but I was surprised to
learn from this thread that a DMA mass storage device on Linux, Mac and
Windows gets unimpeded access to the full stretch of system memory. I
take what I read here with a grain of salt, but the non-nut cases seem
to be out and in agreement, at least about that.

I'm not going to be writing a 20 page paper. I think I have 2 main
questions I'll write about: How much should you worry about this and is
it fixable (beyond disabling DMA, which is not a good solution if you
ask me). You say it's fixable; that still leaves some questions for me
whether the fix comes at the expense just of additional sophistication
in the Firewire drivers or also a performance burden. I'll probably just
leave it at a question.

I actually do have a response fom Microsoft on the broader issue, but it
doesn't address these issues or even concded that there's necessarily
anything they can do about it. They instead speak of the same
precautions for physical access that they spoke of a couple weeks ago
with respect to the "frozen notebook memory" attack - use drive
encryption, use 2-factor authentication, use hibernate instead of sleep,
use group policy to enforce them. I don't think it's a bad response
under the circumstances. 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. 

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.
* 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.

How much should the average user worry about this? Not very much. Most
notebooks from average users don't even have Firewire on them and you
would have an easier time cracking them with a dictionary attack on the
password and other such things, which means that this attack makes you
no more vulnerable to compromise if you've already granted physical
access than you were before. The frozen notebook memory attack seems a
little too Mission Impossible for me to get worked up about. And if
you're the sort of high-value target who needs to worrry about this sort
of attack, there are measures you can take: use drive encryption, use
2-factor authentication, use hibernate instead of sleep, use group
policy to enforce them.

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blogs.pcmag.com/securitywatch/
Contributing Editor, PC Magazine
larry.seltzer@...fdavisenterprise.com

Powered by blists - more mailing lists