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

[monkeydluffy09 (1248486)]

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]

Re:Yes, yes, another anti-windows story

[Oktober Sunset (838224)]

maybe they aren't smart, maybe they are dumb, that means even a dumb ass can crack windows security.

Re:Yes, yes, another anti-windows story

[sumdumass (711423)]

hey now. Not all of us need this crack to bypass windows security.

*listens closely*

[Stanistani (808333)]

"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."

The hard part is...

[lpangelrob (714473)]

...finding a PC with a firewire port.

(The only ones at my workplace are the two I put firewire cards in. Don't ask, it's complicated.)

Re:The hard part is...

[MPAB (1074440)]

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

Re:The hard part is...

[Penguin Follower (576525)]

Sorry, I haven't seen a FireWire port on a PC (lappy or desktop) in about five years.

It could be due to the environment you work in, but there's at least 6 laptops in this office that I can think of that have firewire on them. One is a Toshiba, and the others are a mix of Dell and Lenovos. If I think harder about it, I'm pretty sure the laptops that were sent out to our regional managers (all over the U.S.) had firewire as well. It is worth mentioning that all of these laptops are less than 2 years old, as we went through a refresh not that long ago.

Re:firewire has been around for longer than you th

[bumby (589283)]

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

Re:

[elrous0 (869638)]

As someone who edits digital video, I wouldn't buy a machine without one. Mini-DV is still the best consumer/prosumer video format for SD video and Firewire is absolutely the best way to interface a Mini-DV camera with a computer. Not sure about HD video, but Firewire would probably be useful for that too (since most agree that it's faster than USB 2.0).

Re:The hard part is...

[Beardo the Bearded (321478)]

Physical access = security is meaningless.

If they could access the firewire port via an internet connection, THEN I'd consider this a leak.

You could also tweak the system by opening the case and removing the hard drive, or just attaching a thumb drive and copying all the data.

Re:

[TripMaster Monkey (862126)]

That sounds like a challenge...

Re:The hard part is...

[clickclickdrone (964164)]

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

Re:The hard part is...

[gnick (1211984)]

the physical security at my home is pretty good

That's the gotcha here. Anyone with physical access to a machine owns that box. The only difference with this technique is that it sounds like it's quicker and possibly more subtle than my typical method of rebooting onto a live Linux CD and "repairing" the Windows accounts.

host memory!

[Spazmania (174582)]

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!

[iangoldby (552781)]

Because it is not USB.

Actually, what do I know? But I do believe that Firewire doesn't have the concept of host and slave nodes. All nodes on a Firewire network are equivalent AFAIK.

If it were necessary to explictly allow direct memory access on a node whenever it was requested, you would not be able to plug a Firewire cable into a control-less box (for example) and do things with it, without first accessing the control-less box through a non-Firewire method to enable Firewire DMA.

Anyway, that's my ignorance on the subject. And as Adam Boileau says, it is a Feature, not a Bug. It is intended behaviour, so there must be a good reason (even if it is not the above).

Re:host memory!

[TheRaven64 (641858)]

It's a design flaw. The peer-to-peer nature shouldn't come into it. What ought to happen is that one peer requests DMA rights to a memory location in another peer, and the driver then returns yes or no before the controller decides whether to permit the DMA request. In simple devices, like hard drives, the driver would always return true (allow). In multitasking systems the driver would only return yes for pointers to pages it owns.

Re:host memory!

[Jah-Wren Ryel (80510)]

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.

Physical access

[nickv111 (1026562)]

Not to say that Microsoft shouldn't have patched this, for it is certainly a design flaw to allow computers hooked up to a machine to access its memory, but if you're plugging something into the Firewire port of a computer, then you're sitting at that computer, aren't you? It's true of all hardware that if you have physical access, then you can do whatever you want with it anyway.

-Nick

Up to a point.

[SmallFurryCreature (593017)]

A lot of workplaces will have physically secured machines but nonetheless with ports open. People might notice if you remove a server from a rack to access its insides, but just plugging in a cable?

Yes offcourse, not that many machines have firewire and servers are even rarer (although my pc has a port) but still, there is a major difference between the access needed to open a PC and gets its HD and just plugging in a cable.

See it as the difference between having to steal secret documents and being able t

Re:

[Chops (168851)]

It's true of all hardware that if you have physical access, then you can do whatever you want with it anyway.

That's certainly not true. To use one of a huge multitude of examples, students at my school had physical access to the machines in the computer lab, but it would definitely be a problem if they installed a keylogger to sniff other students' passwords.

Re:Physical access

[SharpFang (651121)]

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.

Done previously

[TripMaster Monkey (862126)]

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.

Re:

[EvilRyry (1025309)]

Any word if Linux and/or OS X have a fix for this issue. Yes, I've read TFA and it doesn't mention it.

Re:

[ockegheim (808089)]

If you're concerned about it, there was another post above which suggested disabling the firewire interface when you're not using it. An applescript that ran a shell command to enable, disable or toggle the firewire interface could just sit on your desktop. Alas, I'm not Unix-literate enough to write the shell script bit though.

Also affects OS X and linux

[mooglez (795643)]

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

[Sycraft-fu (314770)]

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

[Creepy (93888)]

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.

"If someone does plug into your port unexpectedly"

[Chops (168851)]

My favorite part of the article:

Paul Ducklin, head of technology for security firm Sophos, said the security hole found by Boileau was not a vulnerability or bug in the traditional sense, because the ability to use the Firewire port to access a computer's memory was actually a feature of Firewire.

"If you have a Firewire port, disable it when you aren't using it," Ducklin said.

"That way, if someone does plug into your port unexpectedly, your side of the Firewire link is dead, so they can't interact with your PC, legitimately or otherwise."

"You see, this serious security problem was designed in from the start, so therefore... it's not a problem! Ta-da!"

Physical Security

[Chysn (898420)]

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...

[muffen (321442)]

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

Why doesn't MS disable the port on lock?

[pruss (246395)]

Some commenters note that this is a feature of Firewire. But would there be any problem with MS just disabling the port whenever the system is password locked, unless there is something already plugged into the port when the system was locked (after all, there might be a Firewire HD plugged in, and a process writing to it). Probably the best way to handle the latter case would be to watch for an unplug event when the system is locked, and then disable the port as soon as the device is unplugged. This is very simple, and I don't see any downside to it.

Linux has the same security hole

[Animats (122034)]

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.

Doesn't matter

[RzUpAnmsCwrds (262647)]

This "vulnerability" is basically irrelevant for notebooks. Most notebooks have hot-swappable CardBus or ExpressCard slots, both of which have DMA support and can be used to dump the system's memory. Or you could do the "memory freeze" trick.

The correct solution would be to map the FireWire address space into virtual memory, but this has to be done at the hardware level.

Re:Breathtaking Arrogance or Stupidity?

[91degrees (207121)]

This does require physical access to a machine. If you want to access the machine, you can reboot using a USB stick and access the hard disk that way, or even just open the machine and take the drive, then modify the contents to your heart's content before putting it back

Re:Breathtaking Arrogance or Stupidity?

[liquidpele (663430)]

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?

[goddidit (988396)]

But this works with crypted drives.

Re:Breathtaking Arrogance or Stupidity?

[LingNoi (1066278)]

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?

[Albanach (527650)]

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?

[sm62704 (957197)]

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?

[TheRaven64 (641858)]

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?

[by Anonymous Coward]

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

Re:Breathtaking Arrogance or Stupidity?

[TheLink (130905)]

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.

Firewire Target Disk Mode

[Vandil X (636030)]

Ever since Macs have had Firewire ports, you can boot a Mac holding down the T key and its hard disk become accessible via Firewire cable on another Mac. Mac OS X setup even prompts you to do this if you're migrating settings & data from one Mac to another.

Re:Breathtaking Arrogance or Stupidity?

[TheRaven64 (641858)]

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?

[xtieburn (906792)]

Or perhaps slashdot on another uneducated baseless diatribe directed towards that little known company MS.

Did you read the article or did you just check the headline and decide to try get cheap mod points? Ill point out why you dont deserve them.

'Paul Ducklin, head of technology for security firm Sophos, said the security hole found by Boileau was not a vulnerability or bug in the traditional sense, because the ability to use the Firewire port to access a computer's memory was actually a feature of Firewire.'

Now maybe this was just excuses but the fact it came from a third party with no particular connection to MS should have made you pause for thought. Even if you dont know much about firewire it would take you moments to do a quick search and actually realise this is a 'feature' of the actual specification itself. As in _every_ O/S had the same problem. Linux, OSX even BSD were using this exploit even before MS were cracked. There are still reports of new OSX and Linux systems being hacked by firewire right in to 2008. (Though admitedly ive not heard much from BSD, probably because there admins tend to actually have a clue.)

This is a universal flaw in security stemming from naivety with regard to externally connected hardware. You want secure firewire, disable it when you are not using it yourself. That goes for any system, any O/S, any person. End of story.

Re:Breathtaking Arrogance or Stupidity?

[deblau (68023)]

You are either for false dichotomies or against them.

Which is it?

Re:

[betterunixthanunix (980855)]

The command is run on a second system that is connected via firewire.

Here's the thing though: this requires physical access. That makes it a low-salience attack, because gaining that kind of access is only an iota easier than pointing a gun at someone's head and demanding their password.

Re:Interesting, but

[liquidpele (663430)]

I disagree. It gives the attacker admin privileges. That means you can go to the library or kinkos, and install whatever you want to steal credit card numbers or website passwords from the people using those public machines. Sure you could probably do that other ways, but this makes it *really* easy.

Plus, if you were to break into an office you could steal all kinds of stuff from the computers without the owner knowing it had been done. Things that come to mind are architecture drawings, patents, and reading all the CEO's emails.

Re:Who cares?

[liquidpele (663430)]

Someone mod this guy down.
1) The attack effects Linux, Mac, and Windows
2) This is a very interesting hack, very worthy of slashdot. This is why I read slashdot in the first place. 2) I hate reading some guy's baseless rant. Go back to Digg.

Re:2 Year bug report..

[Nevo (690791)]

This is not a Microsoft vulnerability. FireWire devices can access RAM in the host machine, whether the host machine is running Windows, Linux, or MacOS. Any operating system running on a machine withe a FireWire port can be taken over in this manner.