Aging Security Vulnerability Still Allows PC Takeover

Jackson writes "Adam Boileau, a security consultant based in New Zealand has released a tool that can unlock Windows computers in seconds without the need for a password. By connecting a Linux machine to a Firewire port on the target machine, the tool can then modify Windows' password protection code and render it ineffective. Boileau said he did not release the tool publicly in 2006 because 'Microsoft was a little cagey about exactly whether Firewire memory access was a real security issue or not and we didn't want to cause any real trouble'. But now that a couple of years have passed and the issue has not resolved, Boileau decided to release the tool on his website."

Again

There is also another Security researcher who find an efficient way to gain privilege though the hibernation file. Slashdot news: http://slashdot.org/firehose.pl?op=view&id=551924 [slashdot.org]

*listens closely*

"So I tied an onion to my belt. Which was the style at the time. Now, to take the ferry cost a nickel, and in those days, nickels had pictures of bumblebees on 'em."

host memory!

So why exactly is it a desirable feature for a firewire node to be able to access another node's memory unsolicited?

Re:host memory!

So why exactly is it a desirable feature for a firewire node to be able to access another node's memory unsolicited?

Well, for one thing, it should make cracking any of these "untrusted computing" DRM schemes pretty trivial.

Done previously

Maximillian Dornseif demonstrated [matasano.com] this same Firewire vulnerability against Linux and OS X machines in 2005. Adam Boileau just gets more press because he performed the hack against Windows PCs.

Also affects OS X and linux

This same vulnerability also affects OS X as reported here: http://blog.juhonkoti.net/2008/02/29/automated-os-x-macintosh-password-retrieval-via-firewire [juhonkoti.net]

As well, as Linux, as reported in an earlier 2005 report about this firewire feature: http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/ [matasano.com]

Probably for lower overhead

One of the things I always hear in the USB vs Firewire debates is how much lower overhead Firewire is. In informal testing, this certainly seems to be the case. Well, one of the reasons it might be is if it has DMA. You'll find that's how a lot of PCI hardware works. It can read and write directly to memory, it doesn't have to do things through the processor. Keeps system load much lower, it'd quickly peg the CPU if it had to deal with shuffling around all data on the system. However, it also can lead to problems, of course.

Well, if Firewire has the same capability, it would explain why it is much lower overhead than USB, but it would also allow for things like this.

In general, DMA is probably something that needs to be looked at being cleaned up/reworked. It is a non-trivial cause of system instability: Hardware goes nuts (or maybe driver orders hardware to so something stupid), craps on memory it shouldn't system goes down. However anything like that is going to take a back seat to performance, at least in regular PCs. As nice as it would be to have the CPU fully in charge of everything, people aren't going to put up with it if it means a 10x drop in performance.

Re:Probably for lower overhead

No - DMA may help in some cases, as you describe, but you can tell a Firewire drive to copy to another Firewire drive when neither has any physical memory and it will still copy much faster than USB. The lack of a centralized controller (and device registration, scheduling, etc) actually helps keep overhead down. Note that USB can't do that - Firewire is peer-to-peer, meaning each device is aware of other devices in the chain. USB is a master-slave star network and needs a host controller (e.g. a PC).

Firewire was built a hot swappable, high speed replacement for SCSI, and is really more analogous to SATA than USB, but people compare them because they're both used as external buses for peripherals. USB was designed explicitly as a low speed, low power, low cost small peripheral handler (e.g. mice and keyboards) to replace a variety of miscellaneous specialized plugs such as game ports, parallel port, serial port, etc, and thus cost was most important and speed least. Firewire put speed first and cost last. As far as Firewire goes, I think a battle may be coming, with SATA's external plug eSATA, as I expect it to make some gains in the peripheral market, especially in storage. eSATA actually has an advantage over Firewire, because the actual device used for storage is often IDE and therefore Firewire has some conversion to do (ATA is the protocol, IDE the device - often they're used interchangeably).

The problem here is gullibility. Think of it like social engineering - someone calls and asks "We are verifying your bank account pin, can you give it to us?" and you saying sure - it's 1234! That's a lot like what this program is doing. In this case, the device at one end is saying can I have access to your memory? And the device on the other end is saying sure, despite the fact that that giving write access to memory is a lot like giving away your bank account pin (which is why it's really an OS issue, not a firewire issue). Some OS's like Linux only give read access, which means you can see what is in the account, but not take anything out, but Linux (and Windows) allow this to be set by the foreign controller, which is a bug.

DMA access should be limited to non-system memory, if allowed. Unfortunately, that isn't very controllable by current computer designs. I believe the solution proposed and implemented (I've heard about this for Windows 8, I believe) is encrypted floating addresses, so even if you have direct access to memory you don't know where to write it.

Physical Security

Once your machine's physical security is compromised, just about anything can happen. If someone is in your data center or office unattended and hooking up equipment to your PC, you're sort of in a world of hurt anyway.

In related news...

... it turns out, his site is vulnerable to the slashdot effect :)

Linux has the same security hole

Linux has this same bug. It's in "ohci1394.c". I reported this to the Linux kernel mailing list years ago, and the reaction of the kernel developers was to make it a "feature" for "remote debugging" that's enabled by default.

Technically, here's how it works. First, see the OHCI specification [intel.com], section 5.15, "Physical Upper Bound register". This determines the highest memory address into which an external device can store directly by sending a packet. If set to zero, this feature is disabled. That feature is intended for slave devices, like peripherals. On computers with an operating system, it should be zero. It's not.

In the Linux kernel, that security hole was installed in "ohci1394.c" with the comment:
/* Turn on phys dma reception.
*
* TODO: Enable some sort of filtering management.
*/

In early kernels, it was unconditionally enabled [peanuts.gr.jp]. In 2.6, it's enabled by default, but can be turned off.

Also, This patch [in-berlin.de] indicates that this security hole may have been designed into some FireWire controllers, so that the "upper bound register" didn't really do anything, but read back zero.

Re:The hard part is...

Many laptops have Firewire ports, and most modern desktop mainboards do also thanks to te growing popularity of digital video cameras.

Re:firewire has been around for longer than you th

<technical bitching>
That's IEEE 1394 sir. IEEE is an institute.
</technical bitching>

Re:The hard part is...

>have the time to jack into one of my boxes
You must have one sexy PC!

Re:Breathtaking Arrogance or Stupidity?

For Microsoft to have failed to patch an issue such as this must be indicative of either breathtaking arrogance or utter stupidity... or perhaps both

How about apathy? They'll wake up when and if they ever lose market share because of their shoddy product. I mean come on, if I can sell a Yugo at Escalade prices, why should I produce a quality product? That would be stupid. And if I could sell Yugos at Escalade prices I think my arrogance would be understandable and forgivable.

They've been selling an insecure OS for as long as PCs have been networked, why should they secure it now?

Re:Breathtaking Arrogance or Stupidity?

It's not Microsoft's fault, it's a hardware problem. FireWire is a peer-to-peer protocol with commands for using the DMA controller. Any device plugged in via a FireWire port can issue DMA requests. It can dump the entire contents of (physical) memory and write data at arbitrary locations. A FireWire controller ought to only permit DMA to and from regions the driver allowed it to, but most don't. The only work around for this is to either disable FireWire or use something like the Device Exclusion Vector on modern AMD chips to block the device's access to memory.

Re:Breathtaking Arrogance or Stupidity?

Doesn't that also mean that Linux is also vulnerable to Apples firewire design faults?

Re:Breathtaking Arrogance or Stupidity?

Should be. It's a "feature" of Firewire.

Some Mac people figured it out early (at least by 2001)
http://rentzsch.com/macosx/securingFirewire

The FreeBSD people were already using it way back in 2002, quote:
"As you know, IEEE1394 is a bus and OHCI supports physical access to the host memory. This means that you can access the remote host over firewire without software support at the remote host. In other words, you can investigate remote host's physical memory whether its OS is alive or crashed or hangs up"

In other words it doesn't matter what OS it is or whether there is even an OS.

Oh yeah there's also "Linux Kernel debugging over Firewire" but that's recent - 2006.

Re:Breathtaking Arrogance or Stupidity?

It is true that the DMA must write to RAM where the DRIVER tells it to

Not true. DMA stands for Direct Memory Access. The device has direct access to memory. In this case, it is the FireWire controller and, by extension (due to the design of these controllers) FireWire devices.

If you have an IOMMU (e.g. on a decent Sun workstation), you can set up page tables for each device so that they DMA into a virtual address space. Your driver can then define regions which the device can access transparently. On newer AMD chips, you have a Device Exclusion Vector (DEV). The DEV is a sort of IOMMU-lite. It performs access control, but not translation. This means that the host OS (or driver) can mark each page of physical memory as read / write accessible on a per-device basis. On these machines, a well-designed OS or driver could prevent these attacks.

On other systems, it is not possible to prevent this attack. It's also a known problem on FreeBSD and OS X. OpenBSD does not implement FireWire support for the explicit reason that it is impossible to do securely on most systems.

It is the responsibility of the Driver to not write data where the device tells it to, and do proper bounds checking.

You are possibly confusing DMA with Programmed I/O (PIO). On a PIO device, the driver writes data to device-mapped memory or an I/O port, the driver then reads it from here and writes it to wherever it is meant to go. On a DMA device, the driver (or, in the case of FireWire, a remote peer) just tells the device where to write the data and it does so without CPU intervention.

Re:Breathtaking Arrogance or Stupidity?

Maybe. I can't tell if this hack requires rebooting or not. I'll guess no.
If it doesn't require rebooting, then it's a step above everything else because you don't have to mess with bios boot passwords and hard disk passwords (which my work requires you use).

Re:Breathtaking Arrogance or Stupidity?

But this works with crypted drives.

Re:Breathtaking Arrogance or Stupidity?

That's not exactly the same.. Take my library for example all machines are set to boot correctly and the cases are physically locked to their location. Also looks a lot less suspicious when you're not ripping the guts out of a machine that it's obvious you don't own in public..

Re:Breathtaking Arrogance or Stupidity?

This though appears to have the advantage of not requiring a reboot, so rendering BIOS passwords ineffective.

It's all very well to say if someone has physical access all security is compromised. That doesn't mean you need to make it as easy and quick as possible. Now if you lock your computer and pop to the bathroom, a visitor could be in and out of your PC before you get back.

Re:Breathtaking Arrogance or Stupidity?

You are either for false dichotomies or against them.

Which is it?

Re:Physical access

Depends on the length of the (fire)wire. ;)

In case of most of hardware with mid-to-high physical security you need some 15 minutes of totally unsupervised access, it involves removing the case (to reset the BIOS password), rebooting the system (sometimes by power cycling) and generally implies very dirty and easy to detect hack - you do gain the access but you're not stealthy at it.

You plug the inconspicuous cable in the side/back of the PC, stash the laptop under the desk, and walk away whistling quietly. Then you sit down, access your laptop from another one through wi-fi then proceed to download contents of the compromised box, over the firewire cable.