Vulnerability in the Firewire protocol

Why was it forgotten? Maybe because 2 years ago Firewire was not as attractive as it is today, apart from video-editing amateur's point of view, which require high speed data transfers provided by this technology. Maybe because the exploitation of this "vulnerability" needs physical access to a vulnerable system to be exploited. Consequently other vulnerabilities were preferred.

Without going on and on about the reason of this little "oversight," why this technology draws attention once again?

A bit of history

Invented in the 1990 by Apple, Texas Instrument and Sony, then normalized in 1995, Firewire was originally designed to compete (at that time) against USB. Called "i.LINK" by Sony, but more generally known under the name "IEEE 1394", the Firewire interface is a "plug and play" serial interface, allowing isochronous data transfers that is to say, fast and steady. It provides a fast multiplexed communication bus, and can connect all kinds of hot plug devices (up to 63). These are mainly heavy bandwidth consumers such as digital camcorders, cameras, removable hard disks, and so on.
The Firewire communication model is based on a "peer-to-peer" model. Each device can directly interact with another without going through the host controller. The same information can be shared directly to multiple devices simultaneously.

We get over the technical details of this standard, since this is not the purpose of this article, however be aware that several versions exist, which speed rates are ranging from 100Mb/s to over 400Mb/s for version 1 and from 800Mb/s to 3200Mb/s for version 2.

Vulnerability or design error?

In terms of security, the vulnerability surrounding the Firewire technology is the fact that any device plugged on the Firewire port of a computer, can remotely use that connection to get read and write access to portions of the computer RAM. The abuse of that Firewire feature was discussed for a long time. In 2004, Maximilian Dornseif wrote a program to attack a system equipped with a Firewire port via an iPod (cf. the article titled "Owned by an ipod"). In 2005, he formalized his findings in a presentation called "FireWire : all your memory are belong to us" at the conference CanSecWest. In 2006 at the Ruxcon conference in Sydney, Adam Boileau dissected in his "Hit By A Bus: Physical Access Attacks with Firewire" lecture, the functioning of physical access to the memory via Firewire. In his presentation, he focused on the interactions of the access to data stored in memory by the DMA controller (Direct Memory Access) of a host hosting this type of device. The technique involves exploiting the Firewire protocol functions to get read/write access to the entire addressable system memory. To gain speed, the protocol avoids intermediate components such as the processor, controllers, operating systems, etc. To reduce data access latencies, the Firewire protocol directly manipulates DMA controllers. The gain in speed is at the expense of any data access control. The memory is then fully accessible.

Technically the allocation of access rights to the DMA controller is through a simple application of a device to the operating system thanks to two registers called CSR (Config Status Register).

From a security perspective, that feature is actually a design flaw inherent to the Firewire protocol.

Exploitation / Attack

Several techniques exist. The first one is to directly connect a Linux laptop via a Firewire connection to a vulnerable system. Then, launching a dedicated distribution shipped with the "libraw1934" library allows to simulate the connection of a new Firewire device to the host system and to read its memory. The vulnerable system has no idea of any access being made to its system memory. The distribution can then search for system authentication data, and change them. The so-called "winloclpwn" program is the one which brought back the controversy. This demonstration program presented at Ruxcon in Sydney came back to the scene last March. It allows to bypass authentication on a locked Windows session, or to run a shell with the administrative privileges, simply by connecting a fake Firewire device to a vulnerable Windows XP system. It should be noted that Windows Vista thought to be protected against such attack, but it seems that the code of Adam Boileau has been ported and is functional on the latter.

Other programs or Linux distributions use similar techniques and allow to directly change the administrator passwords on Windows systems, or to run malicious code to circumvent access controls, or to recover passwords, private key, which then are easy to "brute force".

Adam Boileau, also describes the many possibilities of exploitation of this vulnerability including among others; keylogger implementation, modification of video memory, DLL injection, installation of rootkits, and so on.

Other uses

Beyond the exploitation of this technique with a malicious intent, it can also be used for other purposes such as application debugging, device drivers development, forensic analysis of memory, malware analysis while it runs in memory, and even retrieving video memory screens (video duplication).

Difficulties

However, there is no need to alarm anybody because the many existing tools are not very sophisticated. Memory recognition techniques, or memory reconstruction, are still immature, and are very time consuming.

This is due to the virtualised structure of the memory address space, in which 4-kilobytes pages are only accessible through several indirections pointers. The memory is very volatile, changing and evolving rapidly and also is fragmenting very quickly. All this makes the task of reconstruction difficult (time consuming).

Programs which try to bypass authentication, must seek for system structures, dynamic libraries within the memory to rebuild the structures used by system function calls, and more generally to rebuild main data structures (e.g. MsGina.DLL, and so on).

Are other systems vulnerable?

Windows systems are "vulnerable", but other systems are also impacted. The "vulnerability" resides on the Firewire protocol design, which does not forbid direct readings or writings in the host system's memory. As such, systems such as Linux or Macintosh OS X are just as vulnerable as Windows systems. One of the first "proof-of-concept" made by Maximilian Dornseif, was addressing this issue through an iPod against Linux system and not Windows systems.

What about USB?

It is legitimate to ask the question, if the competitor of Firewire technology, the USB, has the same weaknesses as its counterpart. Apparently this is not the case. The USB protocol standard does not allow direct access to memory, at least not directly from the USB devices. The operating system and the processor still manage all access permissions to it. The exploitation of direct read/write therefore seems impossible.

How to protect yourself?

The Firewire standard and particularly its system interface called "OHCI-1394" (Open Host Controller Interface) offers little opportunity to reduce the risk of attack through Firewire devices. The reason is simple, as we have mentioned it, this vulnerability is not really a vulnerability, but rather a design flaw. The Firewire standard authorized to have direct access to memory - then it is exploited.

While it is difficult to physically protect Firewire ports, disabling it in the BIOS is simple to anybody. Some systems, such as Macintosh G5, offer the opportunity to password protect Firewire ports. This technique, however, remains marginal.