Bypass full-disk encryption and passwords on any powered-on computer via Firewire.

Inception is a FireWire physical memory manipulation and hacking tool exploiting IEEE 1394 SBP-2 DMA.

The tool can unlock (any password accepted) and escalate privileges to Administrator/root on almost* any machine you have physical access to. [...] It is primarily intended to do its magic against computers that utilize full disk encryption such as BitLocker, FileVault, TrueCrypt or Pointsec. [...]

Inception's main mode works as follows: By presenting a Serial Bus Protocol 2 (SBP-2) unit directory to the victim machine over the IEEE1394 FireWire interface, the victim operating system thinks that a SBP-2 device has connected to the FireWire port. Since SBP-2 devices utilize Direct Memory Access (DMA) for fast, large bulk data transfers (e.g., FireWire hard drives and digital camcorders), the victim lowers its shields and enables DMA for the device. The tool now has full read/write access to the lower 4GB of RAM on the victim. Once DMA is granted, the tool proceeds to search through available memory pages for signatures at certain offsets in the operating system's password authentication modules. Once found, the tool short circuits the code that is triggered if an incorrect password is entered. [...]

The problem is old, but it is not entirely fixable with a driver update, a patch or a new OS version. The problem is in the Firewire specs. All OS vendors that want to include Firewire drivers that are OHCI compliant and works out of the box with SBP-2 devices are vulnerable in some degree. [...]

You can use any interface that expands the PCIe bus, for example PCMCIA, ExpressCards, the new Thunderbolt interface and perhaps SD/IO to hotplug a FireWire interface into the victim machine. The OS will install the necessary drivers on the fly, even when the machine is locked.

So that's, you know, bad.

Previously.

Tags: , , , ,

34 Responses:

  1. jwb says:

    There's some pretty big talk on this page but it's basically a rehash. The vulnerability has been known and implementations widespread since at least 2002 (google for: firestarter). Anyone who ever debugged the MacOS kernel over FireWire obviously knew about this feature. Linux, MacOS, and Windows all disable physical DMA over FireWire by various means (the decent thing to do is disable it by default, but I think on Mac you still have to futz with EFI to turn it off.)

    • jwz says:

      See, when you say things like "But it's been done" I wish you had started your comment with "Meh" so that my killfile would have trapped you before I had to read it.

      This is a working application that you can download now, not theory, or a recipe of things you can maybe sorta type into gdb. That's a big difference.

      "Anyone who ever debugged the MacOS kernel over FireWire" is, essentially, nobody.

      • I think it's more that some of us are jaded about this, having seen the "Hit by a bus" attacks at Ruxcon in 2006, and then winlockpwn by Adam Bolieau in 2008(?), which was a fully functional way of bypassing passwords on Windows machines over FireWire (no gdb involved, promise).

        It's been a while since I saw a machine with firewire, and I haven't seen as much recently about whether eSATA or USB3 can be used for this kind of tomfoolery.

        This stuff really is old hat, at least on the Windows side of things. And there's never been a reason to suppose that patching memory over firewire was going to be a Windows-specific vulnerability.

        • jwz says:

          Wow, it's so great that you chose to tell me, twice, how jaded you are.

          Also it's great that you haven't seen a machine with a Firewire port. That's really fascinating and also irrelevant since this works with other ports too. You didn't even have to RTFA to know that, only my excerpt.

          So yeah, I'm totally impressed at how jaded and old-hat you are. Fantastic insight.

        • Vincent Janelle says:

          Firewire is part of Intel's desktop spec, which is why you were still seeing viaos with vga ports until recently.

          You also missed the parts of the actual attack, which work because you can remotely address memory as part of the firewire spec. eSATA and USB don't have this functionality.

          • Good to know that eSATA and USB don't allow for mapping host memory over DMA.

            Are standard Firewire ports really included on modern machines? I honestly hadn't seen any in quite a while. On the other hand, I did see that Thunderbolt ports are also vulnerable, so that does make it relevant to modern Macs.

            My initial response was a bit out of line; this is interesting and new, it just had the same flavor (and basic mechanism) as something I'd seen a long time ago. Apologies.

            • Vincent Janelle says:

              I think it's an optional part of the OHCI spec.

              VT-d is the defence against it. And whatever the hell AMD calls it.

            • Adolf Osborne says:

              Brendan, this isn't all directed at you, but more at the original concept:

              My wife's (recent AMD) desktop has a Firewire port. My (somewhat recent Core 2) has a Firewire port. My laptop has a Firewire port. Modern Apple machines appear to have Thunderbolt, which seems to be largely an extension of Firewire (as makes sense), and appears to be in the same ilk in terms of being DMA-friendly.

              None of my machines are due for retirement anytime soon, as they're all reliable and quite fast enough.

              And in all of these cases, Firewire was something included in the default factory build.

              That all said: Do I worry about it? No, and I won't -- not ever.

              The tool requires physical access to a running computer in order to do its tricks. And with physical access, a plug-and-play exploit over Firewire is the least of my concerns: It should go without saying that once physical access to the target computer has been reached, all bets are off.

              Meanwhile, issues with physical access are why I have locks on my doors, guns in my house, as well as an upstairs-dwelling dog and a downstairs-dwelling dog, both with hair-trigger responses for anything unusual and a tendency to make a lot of noise and terrify the uninitiated. The dogs are big/scary, they communicate well with eachother, and the combination is an excellent local alarm system and deterrent.

              The guns and ammo are selected more to ruin lives than to end them: An intruder may not die right away, but they're not going to get very far and they've got a good chance of spending a long time wishing they were dead after I order an EMS squad to pick them up.

              Furthermore, I live in a state where it is completely legal to shoot and/or kill an unwanted intruder without prior physical altercation. (YMMV.)

              (And if I really had anything super-seekret to hide, such an attack and many others would be thwarted by simply turning off the machine when not physically and actively tended, cleaning or eliminating swapfiles and never using hibernate or similar, ever, along with a strong passphrase and/or an offline key secured separately from the machine.)

              • Tim says:

                Modern Apple machines appear to have Thunderbolt, which seems to be largely an extension of Firewire (as makes sense), and appears to be in the same ilk in terms of being DMA-friendly.

                Thunderbolt may look similar from the outside, but it isn't from the Firewire family tree.

                Unlike Firewire, its protocol isn't designed to do anything natively. Thunderbolt is an encapsulation layer for packets from other high performance packet buses. At present they have defined how to transport PCI Express and DisplayPort packets. A thunderbolt chip in your computer bundles several lanes of PCIe and DP into a single TB cable. Other thunderbolt chips in devices translate back to physical PCIe or DisplayPort. (If you plug in a TB disk, what's inside of it is a TB-PCIe endpoint chip, a PCIe AHCI SATA controller, and a SATA disk.)

                It's a fine distinction which does not in any sense reduce the security risks, but Thunderbolt itself doesn't do the DMA, the tunneled PCIe link does.

              • jon says:

                "The guns and ammo are selected more to ruin lives than to end them: An intruder may not die right away, but they're not going to get very far and they've got a good chance of spending a long time wishing they were dead after I order an EMS squad to pick them up.

                Furthermore, I live in a state where it is completely legal to shoot and/or kill an unwanted intruder without prior physical altercation. (YMMV.)"

                This is soo cool. I wish I was you and I wish I could be living in a state like that. I really admire the shoot first, ask later attitude of the bad TV cops - this is how justice should work.

                Unfortunately not everyone lives/works in such a blessed place, so - imagine that - there are people out there who do consider others having physical access to their machines.

              • Pavel Lishin says:

                For what it's worth, it may be entirely possible for an intruder to sue you if they survive. It's happened, and they've won.

                So there are benefits to shooting-to-kill aside from not being the type of asshole who'd maim someone just to watch them writhe around in pain, and would then brag about it.

              • Big says:

                "Meanwhile, issues with physical access are why I have locks on my doors, guns in my house, as well as an upstairs-dwelling dog and a downstairs-dwelling dog, both with hair-trigger responses for anything unusual and a tendency to make a lot of noise and terrify the uninitiated."

                Do you realize that for a lot of people, that sentence reads "Meanwhile, issues with physical access are why I have locks on my doors – also, I'm an irrationally-scared crazy person."

            • Carsten says:

              Just popping in here to point out that you're missing the point - you don't need a FireWire port to exploit. Just use an ExpressCard/PCMCIA Card or a Thunderbolt adapter to hotplug a FireWire interface into the target machine.

              Source: I'm the author of the tool.

              • Adolf Osborne says:

                In what way is that not exactly as illogical as saying: "You don't need an engine to drive the car; just install an engine and drive it."

                • jon says:

                  In the same way as it is possible to bring a car engine in your pocket and install it within seconds without even opening the hood or having a car key.

            • Mike Hoye says:

              All iMacs, iMac Minis and non-retina Macbook Pros have Firewire ports, and the business lines of most other major laptop manufacturers have expresscard ports.

          • Jon Dowland says:

            I think VGA ports on Vaios (and other business-class laptops) until recently is more to do with the lack of other options for the majority of projectors in the wild, until recently.

      • phuzz says:

        Maybe you should have also quoted this bit from TFA:
        "DMA attacks has been known for many years, so this is nothing new (except for the fact that I will reverse engineer new signatures and update the tool’s functionality until the problem is fixed). However, vendors generally dismiss DMA attacks as a non-issue, which I hope that the awareness that this tool generates will change. Users deserve secure devices, even when attackers gain physical access."

        Although I'll admit I was thinking "I'm sure I heard about someone doing this years ago..."

    • Tim says:

      This is not a mere rehash.

      The original round of software like Firestarter depended on the target system not having any protection from Firewire DMA. As you note, there was a response -- but it wasn't just "turn it off if you don't want to be vulnerable". I believe what happened was that later versions of the Firewire OHCI host controller spec added features to enable and disable DMA on a per-device basis, and operating systems left DMA off for each device until a driver enabled it.

      What these guys have done is to spoof a very common kind of device which needs DMA access. SBP-2 is the encapsulation protocol for SCSI-over-Firewire, and is used on literally every Firewire storage device. SBP-2 involves the device executing scatter/gather DMA command lists just as if it was a PCI SCSI card. SBP-2 went a bit beyond SCSI and actually defined a standard for how this virtual SCSI host adapter worked, which is why you don't need per-device SBP-2 drivers, just a generic driver bundled with the OS. The weakness is that as soon as the SBP-2 driver matches to an apparent SBP-2 device, it has to tell the host controller to enable DMA for that device, otherwise the device can't function.

      It's been ten years or more since I last looked at SBP-2 specifications but I'm pretty sure there is absolutely no fallback mode -- if you want to have working Firewire disks, you have to be able to enable DMA for them. What's needed is an IOMMU-enabled SBP-2 / Firewire driver stack which exposes only pages the driver stack has intentionally set up as S/G DMA command buffers or DMA data buffers. (Plus, of course, some paranoia code to zero all such pages before marking them as readable or writeable in the IOMMU.)

      Of course, if you don't have an IOMMU, whoops.

      Owning a machine without Firewire is not necessarily protection:

      Apple Thunderbolt Firewire adapter

      SIIG ExpressCard firewire adapter

      These are PCIe OHCI Firewire controllers which plug into your computer via hotplug versions of PCI Express. As these Inception guys note, plug one in and your OS will dynamically load all the required drivers. (Despite what they say, it shouldn't even have to download and install them, although if it's a Windows machine it may go through the ridiculous Windows theater of "installing" device drivers which are already present.)

  2. Peter says:

    The best part is it is relatively well-known for ten years or something like that. And it was always been glaringly obvious to anyone even slightly familiar with PC architecture.

    I wonder how much successful hacks were already performed.

  3. To purge FileVault keys from memory when putting the computer to sleep, run
    sudo pmset -a destroyfvkeyonstandby 1
    (This is documented in many places, I re-found it from http://www.michaelkummer.com/2012/08/05/securing-apples-filevault-2-full-disk-encryption/). This means the attacker can only recover the keys from an unlocked machine.

    (The core issue, if you care, is that FireWire/ThunderBolt/ExpressCard has direct memory access. This means it's incredibly fast, as it doesn't have to pipe files you're copying through the CPU, but anyone who can access the port can access all your RAM.)

  4. bode says:

    This is basically the same thing:

    http://www.schneier.com/blog/archives/2012/12/breaking_hard-d.html

    Bruce tells me:

    "It's getting harder and harder to maintain good file security."

    Anyway, if I read the comments they say the same thing: for a long time everyone has known that you must "completely shut down" for all full-disk encryption schemes to work, and possibly then-some. Sleep (or an actual "on and operating computer") are vulnerable every time, because the keys are always in memory and hence in VM and available. And the commenters even discuss the 1394 attack.

    Also, the above is a "real life working application" that you can buy for $350. Or, more exactly, a "real life applications that the po-lice will buy."

  5. Vincent Janelle says:

    Until recently (10.8.1? 2?) you could do this on any thunderbolt equipped mac if you used the fw800 adapter(after connecting it to a device with a downstream port, like a goflex thunderbolt desktop dock).

    You could only address 32 bits of memory though (so 4GB of ram).

    10.8.1/2 added VT-d (mmu for virtualization, essentially) that protects against the firewire and thunderbolt vectors - but only on the retina macbook pro (IIRC).

    Previous ways of defeating involve setting open firmware passwords, or not using OS X... Which is not really the answer. There's been other commercial tools to do this in the past..

  6. ...any machine you have physical access to.

    So what's the intersection of "attackers who perform in-person cyber-attacks" and "attackers who need turn-key exploits"?

    No doubt this will get used in some dramatic fashion by private sector spies, but I don't see why it should alter my personal threat model.

    • Mike Hoye says:

      So what's the intersection of "attackers who perform in-person cyber-attacks" and "attackers who need turn-key exploits"?

      The cleaning staffer you pay $50 to plug _this_ dingus into _that_ machine and bring it back at the end of the shift.

      • Nick Lamb says:

        Rather than bribe a cleaner you'd usually have a trained person do it, it's easy to get hired as cleaning staff and nobody is alarmed if you jack the job in after a couple of days. Unless the location is really well secured you don't even need a job actually, just dress the same as the regular cleaning staff, carry a black garbage bag (great for stealing physical artefacts like wall charts or print outs without anyone checking) and don't look other staff in the eyes.

        The main defence used in practice is to have small installations and not hire any cleaners. If somebody says they have a secure building, ask them who cleans the place. Correct answers are e.g. "Nobody, it's a real mess" or "We take turns". Anywhere with cleaners, maintenance people etc. you can usually just walk in, take what you want and the only evidence they'll have that you were even there is some low resolution CCTV images of somebody in a cap carrying a black plastic sack.

    • phessler says:

      Hey, can you charge my cell phone? Yea, just plug it into that port. Thanks!

  7. grェ says:

    There are some mitigations however.

    For example, even from the link you posted:

    "* OS X Lion disables DMA when the user is logged out/screen is locked and FileVault is enabled. Attacking will only work while the user is logged in, or if user switching is enabled. The user switching trick only works for versions before 10.7.2, where the vulnerability is patched.
    * If you have a OF/EFI firmware password set on the target Mac OS X, FireWire DMA is off by default."

    Also, for all the folks who bitch about macbook airs and retina macbookpros having soldered RAM, that actually makes cold boot attacks a much bigger pain in the ass (and I've been told, though not from my DRAM friends, so I'm holding off judgement - that some of the newer 1333/1666Mhz DRAM actually flushes much more quickly making cold boot attacks a bit more challenging anyway).

    Also there's a startup http://www.privatecore.com which is attempting to put keys into the cpu's L2 cache (though there may be some academic research which may already make this a hard problem as well: http://static.usenix.org/event/sec11/tech/full_papers/Muller.pdf ). Privatecore's intended target market is creating a secure/encrypted hypervisor for encrypted VMs for 'cloud' stuff, I wish them good luck regardless.

    As for Bitlocker, really the only usable method to attempt to mitigate cold boot attacks previously with that was if your system had a TPM anyway, which stores the key; breaking TPMs isn't unheard of, but there's much more limited public research (let alone public tools); oh and always shutting down or putting your system into hibernate (not sleep). Bitlocker itself is only available on the much more $$$ Ultimate/Enterprise windows licenses as well (at least filevault2 ships with Lion/ML). I think if one is using a TPM, this attack may still be thwarted.

    But yeah, DMA... 0wn3d by an iPod by Maximillian Dornseif was one of the earlier public discussions of this. Elcomsoft has had a tool that was $999 and recently dropped to $299; inception I guess is free? So the fiscal cost (and subsequent likelihood of usage) has been shifting progressively.

    My hat is definitely off to the OS X folks for aggressively working on mitigating this and building it into their OS and even hardware design with no extra cost, I suspect we can gratefully blame Window Snyder (she also lead the Windows SP2 security team) for spearheading some of these improvements though some of the code... they headhunted a guy who worked on PGP FDE to write filevault2 (who's name is escaping me at the moment), which was a godsend, because PGP FDE's EFI loader would lead to an unbootable system just about every time Apple would patch their OS with a . release. Not to mention, there was a period after Symantec bought PGP where they didn't even know how to sell that product for a spell. :(

    Also, OS X specific, there are ways to disable firewire: http://forum.bitstopr.com/threads/disabling-firewire-on-mac-os-x.2670/ (there are some similar things you can do for thunderbolt if you go digging through your fs following such steps).

    The thing that scares me is there are some classes of wireless devices which use DMA, Johnny Cache touched upon some of this long ago, and there was another fellow (who's name is also escaping me at the moment) who dug a little deeper, but very little public PoC. That said, AMD64 and now Intel with VT-d both have iommus, but as far as I know no one is really doing much to attempt to use the IOMMUs to mitigate these kinds of vectors (even though that seems like something particularly useful, though potentially still not tractable).

    That said, Travis Goodspeed's Facedancer work (presented at http://REcon.cx/2012/schedule/events/237.en.html and most recently 29c3) has some good anti-forensic techniques that can be applied to systems cleverly by doing signature detection and fingerprinting of the device attempting to access them even if they're employing write blockers. He focused his work on USB devices, but I don't see why they couldn't be adapted to wider use).

    Some of these are very hard problems to solve; particularly if you still want performance i/o. Though honestly, I'd be happy if my computers just had power and rj-45 or some ghost in the shell fibre thing. I'm kind of tired of all the multiplicity of ports/standards/DMA or not to DMA tradeoffs; give me network access and power, and everything else becomes a 'remote' problem that's a bit different to deal with, but we've done a lot more work into packet filters than these sorts of things by in large.

    • Steve Weis says:

      Hi. PrivateCore is not just keeping crypto keys in cache. All of main memory is encrypted.

      Among academic projects, Tresor keeps keys in a CPU debug register, but is still vulnerable to DMA. CARMA runs a small trusted computing base in the cache without any main memory at all. There is also Cryptkeeper, which attempts to reduce the amount of memory that's exposed to DMA attacks.

      • grェ says:

        Cool, I haven't used privatecore yet (afaik it's not currently available for public use); this is a difficult problem space and I stand by my wishing you good luck part. :)

  8. Line Noise says:

    Obligatory: http://xkcd.com/538/

    • jwz says:

      It is never obligatory. Neither are Dilbert or Garfield.

      • Rick C says:

        If you could find a Garfield that was relevant to this discussion, I think it would pretty much be obligatory.

  9. notacop says:

    This is probably too late and nobody will read this, but anyway - the "firewire hack" is and was already used in investigations, private ones as well as policework. "Da cops" will usually use a commercial tool from Elcomsoft or Passware. These tools are rather limited in what they can do, but really easy to teach and use and cover most of the cases their users will encounter. Firewire cards are part of the "kit" an investigator would have.

    A well equipped police force or forensics company might have someone somewhere who can use a tool like inception. Doesn't mean he or she has time for every case with an encrypted system, though.