eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Physical security attacks are all the rage these days. Two attacks have been described recently that purport to break the physical security of systems with what was thought to be state of the art protection.
The first one, from a couple weeks ago, involves attacking notebook computers in “sleep” mode. Modern operating system such as Vista and OS X are sold with disk encryption features which are supposed to prevent disk access even when an attacker has physical access to the hard disk.
In sleep mode, however, the computer is technically still on, and the system’s memory contains the keys used to access the disk. So, the scenario goes, an attacker can take the notebook, freeze the memory chips in order to preserve their contents, and then remove them from the notebook and put them in a special reader. This device scans the memory for the encryption keys, which are then used to decrypt the contents of the hard disk.
Claims were also made about access memory from systems in “hibernate” mode or even those shut off, but this is, at best a much dicier proposition, since such systems are physically off, the memory is not being refreshed, and probably has only a short time before it is blank.
This whole attack scenario is facinating but strikes me as a little too Mission Impossible for normal users to care about. If you’re the type of high-value target who should actually be concerned about it, there are ways you can mitigate it: Don’t sleep, use hibernate which, as I have said, makes it much harder to execute. Also use two-factor authentication, even just a USB stick with an encryption key in it. Both of these can be forced on users through group policy in Windows.
The researchers insist that none of this matters and that the measures Microsoft recommends will at most slow down the attack. But even they, in their research paper, state (section 7.1) that by following all Microsoft’s recommendations, including the use of hibernate, the attack can be thwarted. Let’s not make too much of this either way; Microsoft is expecting a lot of users in order to defeat this attack, and the attack requires a high level of skill, physical access and quick action. Normal users simply don’t have to worry about this any more than they have to worry about stray meteorites conking them on the head.
The second one is a little more scary but also the subject of some exaggeration. An attacker can completely compromise your system through the Firewire port. If you see stories about how your Windows or Vista system can be attacked in this way, know that’s beside the point. Any system with Firewire (a.k.a IEEE 1394) in it, including Linux and the Mac, is vulnerable to this same attack. In fact, this was demonstrated on the Mac back at PacSec 2004 as the “0wned by an iPod – Hacking by FireWire” presentation (PPT file).
Before I get too deep in technical detail on this, it’s worth pointing out that this is Firewire we’re talking about. It’s standard on Macs and common on PCs, especially new ones, but not standard on them. But unlike the frozen-notebook-memory trick, you don’t have to be Dr. Who to execute it.
It turns out that Firewire ports are frighteningly powerful. DMA, or Direct Memory Access, is a fundamental part of the Firewire, or IEEE 1394, specification. DMA allows a Firewire device access to memory in the PC. The valid reason for this is performance; while the device is reading or writing memory, the PC’s CPU can continue it’s own job. Lesser high-speed ports, such as USB, slow down the system more because they require more attention from the CPU.
Many years ago it was demonstrated that a Mac could be thoroughly compromised over a Firewire cable. “0wned by an iPod – Hacking by FireWire” was the talk given at PacSec 2004 (PPT file). It should have been obvious that the problem is a Firewire one, not a Mac one, and that other platforms were just as vulnerable.
Upon confirming that the attack worked in Windows, Adam Boileau, a New Zealand security consultant, reported it to Microsoft. After a couple of years of not addressing the issue, at least not directly, Boileau released a report and his attack tool on his Web site. I’ve been told by people who have tested it that Boileau’s attack works against Macs and Linux boxes as well.
DMA devices should have surfaced earlier as a security issue, considering the low bar for getting attention in such matters. The key to this one, remember, is that the attacker has to have physical access to the computer while it’s on. If they’re only going to get your PC from you by prying it from your cold, dead fingers, then only your survivors need to worry about it. Physical attacks such as this are definitely a problem, but not the level of problem that remote attacks are.
I was involved in a long argument over certain aspects of this attack and the cold memory attack on the Full-Disclosure and Bugtraq mailing lists. A few things are clear: The typical system is utterly defenseless against this, assuming someone can get at your computer and cable up to it.
My impression from my own long-ago experience with DMA programming (real mode DOS drivers in the 80’s) and my skimming of Windows docs (such as the REQUEST_ALLOCATE_ADDRESS_RANGE function) is that it should be possible for the Windows IEEE 1394 drivers to restrict the areas of memory to which IEEE 1394 devices have access. It seems they are not doing this, at least not for some types of devices.
In order to get his own attack to work the way he wanted, Boileau set up a program on a Linux system to appear to Windows as an iPod. Windows sees the iPod as a mass storage device, and some claim that Windows treats all mass-storage devices this cavalierly. Clearly it treats iPods this way.
Once the fake iPod can access whatever it wants in memory it can engage in many attacks. It can inject code into processes. It can change passwords on the system. It can perform attacks similar to those described by the Princeton cold memory researchers and defeat disk encryption systems such as Windows BitLocker.
Bill Sisk, security response communications manager for Microsoft, says that this is not a software vulnerability but “a hardware design industry issue that affects multiple operating systems.”
Does this mean Microsoft doesn’t believe that more carefully-crafted drivers could be effective against the attack? Sisk sees problems: “A user can possibly constrain a DMA device’s memory access to specific ranges by using the physical DMA type. However, a user can only restrict access by setting an upper bound, which may or may not be supported depending on the hardware. Even if this restricted access was supported, it still would not be enough to provide sufficient protection against an attack. There are DMA types that allow restricted access, but the trade-off is a decrease in performance and additional software complexity.”
This makes it sound like there are theoretical approaches, but big problems with all of them and also that there are device types which, per the spec, require unlimited access. What are they doing about it? “Microsoft is looking into ways to strengthen how Windows interfaces with 1394 Direct Memory Access (DMA),” Sisk said.
Microsoft also points out that unlimited physical access to the system doesn’t enable just the Firewire attack, but many other well-known and effective attacks, such as offline crypto attacks and installing alternate OSs and changing the boot default to them.
Windows does allow you, relatively easily, to disable the Firewire port. This is definitely an effective defense, but will you remember to do it? If you don’t have any Firewire devices it is, perhaps, a good idea to disable your ports until such time as you might need them. Then the job becomes trickier because you need to remember to enable and disable.
Whatever the answer, we also have to start thinking about this with new interfaces, such as eSata. According to the Serial ATA International Organization, “Serial ATA also provides built in support for first-party DMA, removing bottlenecks associated with on-board DMA controllers.” Sounds like more problems. I hope more care goes into the software support for such devices.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack.