1394 Security Vulnerability
Tue, Mar 11 2008 11:27 AM
| Permalink
Following the fairly well understood Internet process of rediscovery, there has been minor storm of "Firewire-based vulnerability" articles and notes around the world. Here's the background, the history, and some comments.
Background:
Firewire (IEEE 1394) was really and truly designed to be a serial memory bus ... kind of like PCI-E, only based on technology that is 20 years older (David James (R.I.P) and I wrote the first drafts in 1987). This means that it's possible to read and write memory locations just like it's done in PCI ... in fact, 1394 was intended to be the serial adjunct to the various parallel busses that were fighting for market share in the '80s: VME, MultiBus (I and II), NuBus (1 and 2), and even the venerable PC-AT bus. A major enhancement to 1394 was it's ability to support isochronous streams (audio and video type data) ... and that was one of the reasons it ended up a commercial success: it could be used as a connection for the new digital camcorders being developed in parallel. But that was only one of the reasons ... another primary advantage was its memory bus architecture, which allowed peripheral devices (primary disk drives) to include a DMA controller that could read and write buffers directly in a computer's memory. This is done using a protocol called "SBP" (serial bus protocol) where the OS' disk driver would create a linked list of disk read and write command/status blocks in its own memory, where each command included pointer(s) to the correct memory buffers. The address of the start of the first command was written to a special address (a "register") in the 1394 memory space of the disk controller, and then a write to another register caused the controller to start reading disk commands out of system memory. As the disk controller executed commands it (optionally) would write status information back to system memory. When the OS wanted to be interrupted (typically at the END of all that processing), it would have the status written to an area that caused the OHCI to generate an interrupt.
The OHCI?
Stands for "Open Host Controller Interface" ... it's the standard architecture for hooking up a computer to 1394. It has various functions, but the most important are:
- to automate the read and write requests to 1394 addresses "owned" by the computer and mapped to "physical memory" coming from devices on the 1394 bus, translating them to native read and write operations on the memory bus of the computer (perhaps via an intermediate bus like PCI) without requiring any CPU intervention, and
- to pass all read write and write requests to 1394 addresses "owned" by the computer, but mapped to "non-physical memory", on to OS driver software so that the OS code can interpret the request and act accordingly, and
- to allow the OS driver software to make read and write requests to other 1394 devices.
The most relevant for the current discussion is number one ... since this is the "bus bridge" function that allows external devices to read and write computer memory just as if they were master devices on the computer's intermediate bus (typically PCI or PCIe).
In normal operation, and with trusted devices, this is actually very cool. It allows SBP disk drives to run at very high transfer rates without much of CPU load, since there are relatively few interrupts. As a matter of fact, some years ago Bob Griswold, a engineer at Microsoft at the time, did some tests that showed that disks ran faster on 1394 through a "native SBP bridge" than they did attached directly to the computer via the ATA bus.
Security problem:
The problem here is that this is only safe for "trusted devices", since a rogue device could read stuff it shouldn't (security problem) or write stuff in the wrong place (crashing software or maybe even hijacking the computer). This was very well understood at the time the OHCI was being defined, so there were two proposals:
- Restrict the mapping between 1394 addresses and computer memory only to "trusted devices" and also (optionally) only to a very specific block that would only be used for I/O buffers, or
- Have the intermediate bus (PCI) run in "virtual space", which means that the addresses and transactions on the intermediate bus are treated the same way addresses and transactions are done in "user space" for programs ... in other words, they aren't trusted and hardware can do good memory protection.
Option number one was required by the OHCI spec, and was used by Apple and Microsoft. Option two was chosen by Sun, since their intermediate bus, "Sbus", already used virtual addresses.
After Apple gained more experience with Firewire devices, the architects there grew to be more and more distrustful of external devices ... not so much because they were concerned about security, but rather because they had run across a number of buggy 1394 devices that would write to the "wrong" address and mess up another device's buffers. Unfortunately, the OHCI option to limit bus bridge operation to a software-controlled block of memory was not commonly implemented. Instead, Apple went the virtual memory intermediate bus on the G5 series (using a hardware feature known as "DART" ... "dynamic address remapping table" or something like that.
But then Apple switched to Intel processors and chipsets, which had no such capability, and now they are back to where they were in G3/G4 days.
Is this really a problem?
Well, it can be. Apple already uses the "trusted device" feature to disable physical access for unknown devices, but it's not hard to build something that looks enough like a disk drive to get full access.
On the other hand, this can be a real problem for any interconnect that allows bootable disks to be installed. Any time a potential hacker gets physical access to a computer it's easy enough just to plug in a new disk drive with compromised code and boot from that. This is a bit more ornate that just snooping around in memory, but that's only because OS coders haven't done too much to keep memory cleaned of plaintext passwords, nor to scrambling blocks of system code around to different physical locations (although Vista does the latter, I think).
Comments
Moving to blogger ...
I don't post too much to my site, and I like to do most of my work offline, so I've been using a range of site tools starting with BBEdit in the early '90s, then Claris Home Page, then Golive, then back to BBEdit, and finally to Rapid Weaver. I even experimented with Wordpress when my wonderful little ISP, Cruzio, made that easily available. I liked how easy RW made my pages easy to edit, and how nice looking all the themes were, and how 3rd party developers were adding useful plugins ... but I couldn't do remote editing like I could with Wordpress. Fortunately one resourceful developer has built a Blogger plugin for RW, and now I *think* I have the best of both worlds.