Archive for March 4th, 2008
There is currently a fluff piece article on hijacking Windows via Firewire floating around. Essentially the attack allows someone to network via Firewire, directly access the memory, and futz with the windows password logic, effectively bypassing it. To this I say, well Duh! I’ve maintained for quite a while that Firewire was inherently insecure. It by design requires direct memory access, which in this case I think is a very bad idea. Internally, a myriad of components use DMA to reduce the load on the processor. Your networking card really doesn’t want to pester the CPU every time a packet arrives, nor does your SCSI controller really want to bother the CPU every time a sector is read. DMA is a necessity within the computer case, but you inherently need to trust the contents of your case to do their job.
The difference with Firewire is that the component that has DMA is now external to the system. Unlike ethernet, where the ethernet card has DMA but the external ethernet connections do not, Firewire is designed so that the external devices have DMA, and said devices could be even be another computer. At the time of Firewire initial adoption Apple shipped it on all of their PowerBooks, so feasibly carrying just a laptop you could sneak into a corporate important person’s office and exploit the DMA of firewire to access their desktop’s memory. Now there are tiny little x86 systems with an ethernet port, on board flash for storage, firewire and USB ports, and everything else you would need for an attack inside a pocket instead of inside a backpack. Either way, a company insider could feasibly exploit it.
I can see the logic at the time for the design, where CPUs were slow so you can’t take a hit interfacing with them, eSATA wasn’t an option for removable disks, USB 1.0 was slow (and also gave a CPU hit), etc. The arguments for allowing DMA were plentiful, and security doesn’t seem like a concern during the specification process during those days. (Bluetooth 1.0 or 1.1 anyone? Heck, even the Bluetooth 2.0 working spec considers security as an afterthought, or how about 802.11 that launched without even WEP)
What bothers me about this article is the level of irresponsible disclosure on the part of Adam Boileau. He claims to have notified Microsoft two years ago and is releasing his tool now because MS didn’t act. If this was a critical vulnerability in SQL Server or IE, I wouldn’t have a huge problem with it (I don’t think full disclosure is a great thing, but at the same time, if a company sits on a critical for two years that is also less than ideal), but the problem is that this is essentially a critical vulnerability in a specification. Asking one vendor to essentially completely break the spec in their implementation (especially a vendor that gets hammered as often as they do for not supporting certain standards and specifications) is naive (how many devices would be broken if the host didn’t allow DMA). MS can champion changes in Firewire (best of luck, since Apple rules that roost) but they don’t have control over it, and any change is necessarily going to be long and arduous. Boileau should have approached a multitude of vendors with his proof of concept, from OS manufacturers (MS and Apple) to PC manufacturers (Dell leaving firewire out of all of their business lineup unless specifically added, with a note about security concerns, would catch IEEE attention), instead of dropping a note to MS and expecting that problem to take care of itself.
Apple probably wouldn’t have listened, they don’t really have a presence in corporate America where this attack would be most damaging nor do they exude much concern over security, but PC manufacturers likely would be a bit more receptive(hey, we get to cut out a component and claim it is to make our customers more secure in the same breadth). Hitting MS alone and expecting them to muscle the rest of the industry into changing is essentially asking them to take an action that in the past has gotten them in a lot of trouble. Even if all parties concerned were committed to change though, it would take time to update the specification with all of the politics involved, and they can’t just drop support for all existing firewire devices on the market now. At best you could change certain default behaviors.
I guess the lesson here is that if you subscribe to the notion that full disclosure is morally justified so long as you have given the company proper notice, make sure the company has any power to realistically change the issue you are complaining about. Otherwise you are just sort of an ass, taunting them with a vulnerability they don’t control.
~Joshbw