Slashdot Mirror
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."
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
Maximillian Dornseif demonstrated 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.
____
~ |rip/\/\aster /\/\onkey
+1 for the above poster. As far as windows machines, arent there numerous floppy disk/cd tricks that allow you to change the windows password/make it blank IF YOU HAVE ACCESS TO THE DRIVE? How is this news other than its anti MS?
"There is no real right or wrong, just what the majority accepts at the time."
And what stops someone from doing the same thing against Linux?
See my previous post on that subject.
____
~ |rip/\/\aster /\/\onkey
With this hack, you can spawn a command prompt with admin rights directly from the login screen. No reboot required.
____
~ |rip/\/\aster /\/\onkey
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
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/
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.
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).
SJW: Someone who has run out of real oppression, and has to fake it.
Comment removed based on user account deletion
There also happens to be a fix for Mac and Linux too.. What's your point?
Because he linked to the main story. It's the same link in the summary. That's redundant.
My laptop has one, my workstation at home has one and all the PCs at work have them. They're all Windows PCs. Firewire isn't rare; it's possibly just rare for people to use it. Partly, I expect, because USB2 is faster (at least on paper).
Yeah, I had a sig once; I got bored of it.
He didn't say it's not a problem, he said it's not a bug or vulnerability in the traditional sense.
It's also not a Windows issue, because it's the nature of Firewire itself. Which is why this hack can also be done on Linux and OSX, although TFA doesn't bother to mention this.
This is why my laptop has a big button on the side that enables/disables Firewire, and it's disabled by default on boot. I'd have to "opt in" to this vulnerability.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
Mind you I'm not a hardware guy, but I saw this very exploit used over Firewire on a pre-OSX Macintosh at MacHack years ago. The entire audience did the ew, ah, thing and withdrew in horror. Subsequently nothing was done to fix Firewire or the fact that remote devices could write whatever they wanted and exercise whatever privilege on the host device. I suspect that this is the same thing we see here and it is surprising that such a vulnerability exists. There's blame to go around, I'm sure but it seems unlikely if this is a hardware vulnerability that anything Microsoft could do would really fix the problem short of breaking Firewire support entirely.
Whose spec was this anyhow? While blame is shared according to Wikipedia, Firewire was Apple's interface design.
<technical bitching>
That's IEEE 1394 sir. IEEE is an institute.
</technical bitching>
Hey! That's my sig you're smoking there!
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.
Actually, ignore my comment about the Firewire button -- I've been up since 3:00 am. It just occurred to me that the button I'm thinking of actually enables/disables Bluetooth, not Firewire. My bad. I don't have the laptop in front of me right now, and of course I don't use either Firewire or Bluetooth, so I've never actually used the button in question. There's also a button to enable/disable wi-fi -- which I do use, and it seems to me that only works when the laptop is unlocked. Again, I don't have the laptop here to verify that.
So, going back to my original post, maybe there should be a button like the one I described, since this is the nature of Firewire and not a Windows problem as TFA suggests.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
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.
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, 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. In 2.6, it's enabled by default, but can be turned off.
Also, This patch 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.
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.
Sure, but if the system is live and has the EFS mounted
EFS isn't a partition encryption system, so there's no mounting involved. Each individual file has its own file encryption key.
What you said applies if the account whose data you want is already logged in and the machine merely locked, but not if the account isn't logged in, in which case the EFS key is not loaded yet and won't be decryptable without the real password.
(Bitlocker, on the other hand, is a volume-encryption system, like TrueCrypt.)
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.
Up, Up, Down, Down, Left, Right, Left, Right, B, A, START
For the Macintosh line, all the high-end machines since about 2000 have
had Firewire. It trickled down to the iMac/iBook in 2003. So if one
believes the 'five years after it's in a Mac' rule, high-end Wintel
will be likely to have Firewire from 2005, and low-end Wintel
will be picking up that 'feature' this year.
Plan for the future: expect Firewire.
Firewire is a one-stop solution for external hard drives, for digital video,
for HD video, for fast TCP/IP. The use as a maintenance back-channel
into your files is also extremely important to some of us (makes lots
of data transfer/recovery issues easy to solve).