Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Microsoft Security

Aging Security Vulnerability Still Allows PC Takeover 282

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."
This discussion has been archived. No new comments can be posted.

Aging Security Vulnerability Still Allows PC Takeover

Comments Filter:
  • Again (Score:5, Informative)

    by monkeydluffy09 ( 1248486 ) on Tuesday March 04, 2008 @08:48AM (#22634708)
    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]
  • by lpangelrob ( 714473 ) on Tuesday March 04, 2008 @08:48AM (#22634712)
    ...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: (Score:2, Insightful)

      by Anonymous Coward
      Try looking at a modern laptop. They're far more common there than on desktops.

      Hmmm... what a coincidence, laptops are also exposed to strangers carrying computers of their own, too. I wonder if this might have implications regarding the severity of this particular weakness...
    • by MPAB ( 1074440 ) on Tuesday March 04, 2008 @08:52AM (#22634758)
      Many laptops have Firewire ports, and most modern desktop mainboards do also thanks to te growing popularity of digital video cameras.
    • Two of my desktops and all of my laptops have Firewire ports. However, the physical security at my home is pretty good. I highly doubt someone is going to be able to break in and have the time to jack into one of my boxes before the police arrive.
    • by Lumpy ( 12016 )
      not really, most better laptops come with them now. even the low end Dell laptops we bought for customers gifts last november had them.

      After checking the office Pc's around me 50% have a firewire port on them. Dell and Lenovo mix is what we have here.

      Granted we might be wierd here in our buying habits, but we never spec for having firewire on them.
    • by stg ( 43177 )
      Really? Both of my latest desktops (and one is 4 years old!) and my notebook have firewire ports.

      Perhaps that is because I always buy the best (reasonably-priced) Asus motherboard available...
    • by Quarters ( 18322 )
      How much more complicated than "shut down computer, open case, install card, close case, reboot computer, install drivers" was it?
      • I was thinking the same kind of thing, but then realised that he meant something like "don't ask why I needed to install firewire into these machines". At least I hope he meant that.
    • Re: (Score:3, Informative)

      by 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).
    • Every thinkpad I've used for the last three years has had a firewire port.

      As I don't use it on a daily basis - it's disabled for such reasons. Fewer active ports - fewer points of entry.
    • In my days as a technician.. way back in the dot bomb days, I would have to say that alot, I figure about 75% of the systems I looked at had FW headers on the motherboard, but only a few of them were actually connected (most of them were Sony based), so while you may not have the connector, you probably do have the headers.
    • by Beardo the Bearded ( 321478 ) on Tuesday March 04, 2008 @11:52AM (#22637038)
      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.
  • host memory! (Score:5, Insightful)

    by Spazmania ( 174582 ) on Tuesday March 04, 2008 @08:49AM (#22634726) Homepage
    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! (Score:4, Interesting)

      by iangoldby ( 552781 ) on Tuesday March 04, 2008 @08:59AM (#22634842) Homepage
      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! (Score:4, Insightful)

        by TheRaven64 ( 641858 ) on Tuesday March 04, 2008 @09:24AM (#22635088) Journal
        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! (Score:5, Interesting)

      by Jah-Wren Ryel ( 80510 ) on Tuesday March 04, 2008 @09:28AM (#22635138)

      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.
  • by LingNoi ( 1066278 )
    This isn't the first guy to get frustrated with Microsoft's lack of commitment in the security vulnerability area and just release his nasty onto the world.. It probably won't be the last either.
    • by Nevo ( 690791 ) on Tuesday March 04, 2008 @11:36AM (#22636834)
      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.
  • Physical access (Score:3, Insightful)

    by nickv111 ( 1026562 ) on Tuesday March 04, 2008 @08:54AM (#22634786)
    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
    • 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

    • As mentioned before, this potentially allows access to mounted encrypted disks, passwords in memory, and bypasses physical locks on machines and bios passwords.

      Armed with this on a PDA like device I could walk through a room of computers and discretely compromise one after another -provided they have firewire ports, which are probably rare in public and corporate computers.
    • Re: (Score:3, Insightful)

      by 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: (Score:3, Insightful)

      by gad_zuki! ( 70830 )
      Yeah, if Im sitting at it I can boot from USB, wipe the administrator password, reboot and log in. No need for a fireware card, cable, etc. I can do the same with OSX but I have to use the install disc instead of the USB keychain in my pocket.

      Yes this is all very "shocking." This is the slashdot equivalant of CNN playing that lock-pick video over and over again.
      • Re: (Score:3, Insightful)

        by Culture20 ( 968837 )
        This hack can be done on a machine that has its case physically locked, its bios set to boot only to the HDD, and a good bios-setup password. It's the firewire equiv to a remote exploit over the 'net, because the OS you want to own is _running_ at the time.

        The only saving grace is that someone must be physically present to plug in a device. This is still an issue though; imagine how many machines might be pseudo-public terminals, locked down (w/o epoxy in the firewire ports), but are so easily own-abl

    • Re:Physical access (Score:5, Interesting)

      by SharpFang ( 651121 ) on Tuesday March 04, 2008 @09:59AM (#22635466) Homepage Journal
      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.

    • Re: (Score:3, Insightful)

      by Seraphim_72 ( 622457 )
      I agree that if you have physical access to a machine you own it, but at the same time there is a world of difference between being able to do a drive by cracking and physically carting off the machine to brute force it at your leisure.

      Sera
  • Done previously (Score:5, Informative)

    by TripMaster Monkey ( 862126 ) on Tuesday March 04, 2008 @08:55AM (#22634790)
    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.
    • 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: (Score:3, Informative)

        by 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.
      • This PDF [hudora.de] shows how you can filter Linux and Mac firewire.. No idea if this has been integrated into the distros..

        Page 37 for Linux, 38 for Mac
      • Re: (Score:2, Interesting)

        by cobaltnova ( 1188515 )
        As for Debian, it looks like unstable firewire stack implementation (JuJu) handles the security issues. [nabble.com] However, that same article suggests that Lenny (the next version of Debian) will probably be released with the vulnerable, stable stack because it has more compatibility.
  • by mooglez ( 795643 ) on Tuesday March 04, 2008 @09:02AM (#22634884)
    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]
    • Re: (Score:3, Interesting)

      It sounds like it is a problem with firewire and therefore any system which uses it?

      Not to say it should not be patched in all systems, but surely this would have had to be written into the driver deliberately for it to work, so the real question is why firewire requires direct access to the system memory (and potentially passes this onto the external device) when USB does not?
      • by Sycraft-fu ( 314770 ) on Tuesday March 04, 2008 @09:49AM (#22635348)
        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.
        • by Creepy ( 93888 ) on Tuesday March 04, 2008 @12:15PM (#22637508) Journal
          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.
    • Having worked with (possibly alongside is closer) Adam in the past, that's not the point. In all probability, this hasn't occurred to him. It would still be interesting to test, but let's face it, isn't bashing windows the main point here. Whether such and such getting_more_obscure_hardware breaks is one thing, but it breaks in windows! And in truth, if your security is compromised to the point where people can plug things in, it's essentially useless anyway.
    • Mod parent down (Score:2, Informative)

      by LingNoi ( 1066278 )
      There also happens to be a fix for Mac and Linux [slashdot.org] too.. What's your point?
    • by t35t0r ( 751958 )
      Anyone know if this affects all Linux kernels?
  • by Chops ( 168851 ) on Tuesday March 04, 2008 @09:10AM (#22634954)
    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!"
    • Re: (Score:3, Informative)

      by Rary ( 566291 )

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

      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.

  • Physical Security (Score:5, Insightful)

    by Chysn ( 898420 ) on Tuesday March 04, 2008 @09:23AM (#22635076)
    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.
    • If you're leaving your guest for 3 minutes alone, Windows-L seems to be sufficient security feature. Physical access is not a silver bullet. It still requires time to be useful - 3 minutes is not enough to cycle power, remove cover, reset BIOS, boot LiveCD, install a trojan then reboot back to the original OS, log in as that other guy (using the trojan) and re-lock the console. OTOH plug your laptop in, using an automated script upload a trojan over firewire, remove the plug - that looks more like 30s of wo
  • by muffen ( 321442 ) on Tuesday March 04, 2008 @09:23AM (#22635078)
    ... it turns out, his site is vulnerable to the slashdot effect :)
  • by pruss ( 246395 ) on Tuesday March 04, 2008 @10:07AM (#22635586) Homepage
    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.
  • Or I could use a bootdisk with a password hash file modifier...
  • Old Vulnderability (Score:3, Informative)

    by shagoth ( 100818 ) on Tuesday March 04, 2008 @11:03AM (#22636392) Homepage
    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.
  • by jafiwam ( 310805 ) on Tuesday March 04, 2008 @11:06AM (#22636430) Homepage Journal
    So what?

    There's dozens of other ways to compromise a PC (Windows or not) if you can sit down in front of it. Even if you don't have to reboot with this, or can sniff enough stuff to log in remotely later across the internet...

    This is why the server room and racks are locked, it's really really hard to combat against someone who as physical access and a bit of time/knowledge to use to evil ends.

    Sure, it's creative but come on...
  • by Animats ( 122034 ) on Tuesday March 04, 2008 @12:01PM (#22637180) Homepage

    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 (Score:5, Insightful)

    by RzUpAnmsCwrds ( 262647 ) on Tuesday March 04, 2008 @01:51PM (#22639500)
    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.

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Working...