RE: Firewire threat to FDE
Hagai Bar-El wrote on 18 March 2008 10:17: 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? Yes it is, without redesigning the PCI bus. A bus-mastering capable device doesn't need any interaction with or acknowledgement from the host, it doesn't need any driver to be loaded and running, it just needs electrical connectivity in order to control the entire system. (I suppose you could disable the BAR mappings when you go to locked mode, but that's liable to mess up any integrated graphics set that uses system memory for the frame buffer, and you'd better not lock your terminal while your SCSI drives are in operation...) cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Firewire threat to FDE
On Wed, Mar 19, 2008 at 02:25:36PM -0400, Leichter, Jerry wrote: [This has been thrashed out on other lists.] 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. The OS can program the Firewire controller not to allow DMA. 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. Isn't what you're describing here an IOMMU? David. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Firewire threat to FDE
Hello, 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?RSSNewsID=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? Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Firewire threat to FDE
| 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?RSSNewsID=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]