| 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 [EMAIL PROTECTED]