Firewire threat to FDE

[Leichter, Jerry]

| As if the latest research (which showed that RAM contents can be
| recovered after power-down) was not enough, it seems as Firewire ports
| can form yet an easier attack vector into FDE-locked laptops.
| 
| Windows hacked in seconds via Firewire
| http://www.techworld.com/security/news/index.cfm?RSS&NewsID=11615
| 
| 	The attack takes advantage of the fact that Firewire can
| 	directly read and write to a system's memory, adding extra speed
| 	to data transfer....
| 
| IIUC, the tool mentioned only bypasses the Win32 unlock screen, but
| given the free access to RAM, exploit code that digs out FDE keys is a
| matter of very little extra work.
| 
| This is nothing new. The concept was presented a couple of years ago,
| but I haven't seen most FDE enthusiasts disable their Firewire ports
| yet.
| 
| Unsurprisingly:
| 
| 	Microsoft downplayed the problem, noting that the Firewire
| 	attack is just one of many that could be carried out if an
| 	attacker already has physical access to the system.
| 
| 	"The claims [...] are not software vulnerabilities,
| 	but reflect a hardware design industry issue that affects
| 	multiple operating systems," Bill Sisk, Microsoft's security
| 	response communications	manager, told Techworld.
| 
| It is not *their* fault, but being a company that pretends to take
| users' security seriously, and being at a position that allows them to
| block this attack vector elegantly, I would have gone that extra
| half-mile rather than come up with excuses why not to fix it. All they
| need to do is make sure (through a user-controlled but default-on
| feature) that when the workstation is locked, new Firewire or PCMCIA
| devices cannot be introduced. That hard?
Just how would that help?  As I understand it, Firewire and PCMCIA
provide a way for a device to access memory directly.  The OS doesn't
have to do anything - in fact, it *can't* do anything.  Once your
attacker is on the bus with the ability to do read/write cycles to
memory, it's a bit late to start worrying about whether you allow
that device to be visible through the OS.

Note that disks have always had direct access to memory - DMA is the
way to get acceptable performance.  SATA ports - uncommon on portables,
very common on servers - would be just as much of a threat.  Same for
SCSI on older machines.

Normally, the CPU sets up DMA transfers - but it's up to the device to
follow the rules and not speak until recognized.  But there's no real
enforcement.  (Oh, if you start talking out of turn, you might hang
the bus or crash the system if you collide with something - but that's
like very rare, and hardly an effective protective measure.)

The only possible protection here is at the hardware level:  The
external interface controller must be able to run in a mode which
blocks externally-initiated memory transactions.  Unfortunately,
that may not be possible for some controllers.  Sure, the rules for
(say) SCSI might say that a target is only supposed to begin sending
after a request from an initiator - but it would take a rather
sophisticated state machine to make sure to match things up properly,
especially on a multi-point bus.
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com