Schneier on Security

Those who don't use Firewire could always disable the port.

... with superglue.

"Full disk encryption"? Didn't we discover recently that the RAM contains the key for encrypted disks?

Surely the disk key is stored in RAM somewhere, and thus even a full disk encryption is pointless against this attack?

Disk encryption should still help if the attacker is starting on a cold machine... fully powered down not in hibernation or sleep mode. Personally i am glad i went cheap on my laptop, no firewire, no pcmcia slot...

"Full disk encryption seems like the only defense here."

The only defense? How about saying "no thanks" when the attacker asks, "Hey, can I connect this cable from my computer to yours?" ?

The old adage, "physical control is everything", seems particularly relevant here

It should be pointed out that this attack affects any OS that implements Firewire, including Macs and Unix machines.

Bruce,

What intern put this on your blog! This is not the Bruce I know .....

If the machine is running disk encryption is not helping you here. Encrypted files maybe if the user is not saving the password in memory.

cheers m8

The only solution is to disable DMA from firewire external devices.

Full disk encryption is only a solution to protect shutdown/sleeping computers.

(this vulnerability is know since 2004, and identified by CVE code CAN-2004-1038)

As has been pointed out, Full Disk Encryption is of absolutely no help in this situation.

Princeton's recent ColdBoot (http://citp.princeton.edu.nyud.net/pub/coldboot.pdf) paper showed that Full Disk encryption keys can be pulled from memory. Therefore, using this attack, an attacker can easily gain the encryption keys using the same mechanisms discussed in the above paper. This is nothing more than a different method to get a full memory dump, and it would probably be more reliable.

Full-disk encryption will help. Remember that the situation isn't an attacker attaching a Firewire device to a powered-up machine, it's an attacker stealing the machine and using a Firewire device to try and attack it. If the machine was fully powered-down (not in sleep or hibernate mode), then when it powers up the password *will not* be in memory. It'll have to be entered by the attacker into the appropriate dialog during boot. But the attacker doesn't know the password, so he can't enter it. The disk remains encrypted, and not all the DMA access in the world can decrypt it without the password (assuming the encryption is strong).

If the machine is in sleep or hibernate mode with the contents of memory preserved, of course, all bets are off. In that case the attacker doesn't need to extract the password, since the system will decrypt the disk for him once the password prompt at wake-up has been bypassed.

A similar FireWire attack against Pointsec full disk encryption has been published.
http://www.darkreading.com/document.asp?doc_id=148110&WT.svl=wire_1

Surely it shouldn't be too difficult for the OS to disable the FireWire port when the screen saver is active?

If they already have physical access to the computer, then it's all over anyway.

This is memory patching we are talking about. The cross platform question you have to ask yourself is this :

Can you boot without authentication up to a point were the security subsystem is loaded in memory ?

If the answer is yes, you are vulnerable to hardware based attacks.

Full disk encryption is a way of requiring authentication to boot. FDE like BitLocker in TPM only mode will not prevent hardware attacks.

Disabling Firewire... and disabling PCMCIA too!
Otherwise plugging a Firewire Pcmcia card brings it where it's not available...
cf http://security4all.blogspot.com/2008/03/unlock-windows-pc-without-password.html

I find it interesting to see the time delay between the Mac and Windows security worlds - the first Firewire DMA-based hack I remember was the 2002 FireStarter attack. Apple modified their drivers to disable device DMA by the time 10.3 came out.

This was very widely discussed in various Mac news forums, blogs, etc. and a few security conferences. At some point the Linux crowd started making the same fixes and yet, somehow, it took half a decade before this finally got the Windows security community?

@Walter:

That can't really be done. What if you've got an external drive connected and something is using it while you're away from the monitor? You don't want that to shut down.

What if people are logged into the machine remotely via ssh or vnc or rdp or whathaveyou? Is it easy to tell when the 'screensaver' is on then? Sure, this could be configurable for the end user, but that's a pain.

Re: Todd Knar

Some modes of full disk encryption, such as bitlocker basic, will not protect you against this. The password may not be in memory but in basic bitlocker mode, the disk crypto keys. Once you have those, you can extract the SAM file and start cracking.

If you can attach a kernel-mode debugger to any Windows box (requires a firewire or serial-port connection), you completely "own" it in every way that is possible to own a machine.

Full disk encryption prevents changing the boot.ini file, which defeats this easy way of attacking a machine that you have physial access to.

It wouldn't seem to prevent the attack described in TFA, however. I knew there was a reason that I uninstalled my firewire driver and physically disconnected the port.

This is a serious problem for computers in public places, such as teaching labs, libraries, or computer shops. The only realistic way to protect such computers from this sort of attack is to disable the firewire ports (and of course other ports like PCMCIA which provide access to the internal bus).

It could also be a problem for people with access to very valuable data or systems who use laptops in public places, e.g., while traveling. In principle at least the attacking device could be made small enough that it could be attached to a laptop without being noticed.

Todd Knarr: the attack isn't necessarily against a machine that's switched off, or even in hibernation. It's so easy and quick that there are plenty of situations it could be used against machines that are running.

Gotta love the "security experts" who say this shouldn't be surprising and that's it's a "feature". Somehow the phrase "defective by design" springs to mind!

@Harry Johnston

It certainly isn't surprising to anyone who knows how firewire works. Unauthentcated DMA is an integral part of the system and the ability to do this kind of thing has been pretty obvious since it was introduced. The only surprising thing is that people are still surprised that you can break computer security with it.

As for "defective by design", I would prefer to characterize it as "consciously trading security for performance". The ability to do DMA adds a great deal of performance. I'm sure that the designers knew it could be used to defeat security, but it's also fairly well known that you're doomed against an attacker with physical access anyway. Most OSes probably have vulnerabilities in their USB stacks which could be used to similar effect, and most computer allow rebooting from a CD or memory stick with arbitrary contents.

This was demonstrated a long time ago. USB or FireWire devices can use DMA to bypass the OS and all of its protection mechanisms. It just goes in and reads your memory directly.

It's one of those 'doh' moments when you realize how it works, and it demonstrates how security is a hard problem because you have to prove a negative (something can't happen) rather than a positive (like the rest of the requirements).

From 2005:
http://peripherals.hackaday.com/2005/11/09/dont-trust-your-hardware/
http://md.hudora.de/presentations/#firewire-cansecwest

Harry: I tend to notice people trying to plug things into a machine I'm using. :) And my rule of thumb is that if I'm not in physical control of the machine (eg. I've gotten up to go do something away from the machine) it's the same as it being in the physical possession of an attacker and should be secured appropriately.

And yes, bus-mastering DMA is a feature. It's heavily used by almost all the hardware in your computer, from the disk drives to the video card. It's also applicable to eSATA interfaces, BTW.

I have seen gaffed mice that contain a usb drive for that instant malware installation experience.

Autorun is as much of a danger as these DMA hacks.

It surprises me that any workplace allows Windows to be used. (He says posting from work on a Windows machine.)

You can physically lock off your USB ports: http://www.pcguardian.com/products/data.html

I wonder how long it will be before there's a product like this for firewire?

Michael:

The point is most people don't know that they're trading away their security by having a firewire port active. At least the silly things should come with a health warning!

Physical access to a machine by an attacker should not, and, if the designers did their job properly, would not, mean that you are "doomed". Of course you have to make sure the attacker can't open the case, but that can be satisfactorily addressed.

For example, in our teaching labs, the computer cases are wired to the alarm system.

Todd:

If a pickpocket can remove your wallet without you noticing, it doesn't seem much of a stretch to plug something into your computer.

Alan:

I'm told autorun has secure defaults in Vista. And even in Windows XP it can be turned off. Unfortunately as yet no version of Windows allows you to disable DMA on external devices.

I saw metlstorm (aka Adam Boileau) demonstrate this at Ruxcon 2 years ago. I don't see how full disk encryption resolves anything. You're writing to memory, and full disk encryption necessitates transparent access to the filesystem - once the filesystem has been unlocked all the standard file operations will work.

He also demonstrated pulling the encrypted disk password out of memory on a linux box he plugged into via firewire. It was truncated after (i think) about 16 characters, but many people may not have passwords longer than that anyway.

This may be defense after the fact, but having configurable memory areas on the firewire chip will mitigate this. If the OS (or perhaps even the bios) can configure the chip to allow access to only certain memory areas then it's just another shared memory space, albeit one accessed without the OS's knowledge. But the OS remains in control insofar as letting the chip know which areas of memory it is permitted to make visible over the firewire port, and anything else is unavailable.

Harry: a pickpocket gets at my wallet by approaching from where I can't see him, or by distracting me for the moment it takes to get my wallet from my pocket. By contrast, my laptop's in front of me and I'm looking at it, and he's going to need to have the Firewire cable plugged in for considerably more than a second to do anything. Even the best pickpocket won't be able to lift my wallet if doing so requires him to stand in front of me rummaging through the 6 inner pockets of my coat to find the wallet.

Probably being very ignorant here, but is it not possible to store the key on a removable usb stick rather than in memory? (removable so you could take the stick with you if you leave the machine unattended and/or asleep/hibernated.)

If it's not possible for the key that handles sleep/hibernation/wakeup of an FDE-ed OS to be on a removable stick, is it possible to have all encryption/decryption requests immediately beyond waking the machine up use a separate key that could be on a removable stick?

Finally, what about plausible deniability whereby if you do use a separate stick, you'd have two passwords for use on wakeup, one of which would be a duress' one to awake to a deniable OS and wipe memory?

@Todd Knarr:

I will concede, that in the event that the system is completely shutdown, than Full-Disk Encryption will mitigate this attack.

However, there have long been means to bypass the Windows log-on prompt if you have physical access to the machine. From that perspective, while the ability to bypass Windows logon is interesting, it is not a particularly new or frightening attack vector.

What can be gained from looking at the memory of a running machine via this exploit is more interesting, and more frightening. At least partially because full-disk encryption and other security technologies have little effectiveness under these circumstances.

Todd: I don't see why an automated attack (inserting a rootkit, for example) couldn't take place in a second or less once the cable/device was attached. And you aren't likely to be looking at your laptop every second, even when you're using it.

However, I'd guess neither of us know all that much about the art of picking pockets, so the debate is probably pointless. (I'm sure James Bond would be able to do it, though!)

Without physical security, there are any number of ways to compromise the system.

To mitigate this attack, have a false firewire port that triggers a thermite reaction if used. ;-)

A lot of silly comments here about the value (or lack thereof) of Full Disk Encryption. I run PGP Whole Disk Encryption on my laptop. Lets face it, if someone has physical access to my machine while it is running, then it is possible to recover the password in RAM (I don't have a Firewire port, but someone could do the cold boot).

But that's not the risk I'm concerned about with Whole Disk Encryption. Rather I'm concerned about the situation, which is common, where my laptop is turned off and being transported while I travel. If it is stolen, I don't want to end up in the papers as one of those idiots who lost all his company's SSNs, etc.

For ameliorating this risk, whole disk encryption works great. Someone who steals my laptop bag has to guess my long-assed secure passphrase to get at the data. Good luck.

Similarly, I occasionally transfer highly sensitive data on external hard drives from one machine to another. Yes, if you have physical access to either machine you could gank the password that I'm using on the Truecrypt volume of the external hard drive. But again my main concern is keeping the data safe should the hard drive be stolen in transit.

Just because its not magic pixie dust doesn't mean disk encryption isn't useful.

Brian:

Did anybody say disk encryption wasn't useful? All I can see is people saying that it isn't useful against this particular attack, which is true (depending on the particular scenario you're imagining and on the details of the disk encryption technology).

> Surely it shouldn't be too difficult for the OS to
> disable the FireWire port when the screen saver is active?

Great... So when I'm downloading a video of my kids from my camera, I'll need to put the mouse into the automatic-rocking crib? (Or perhaps just remember to disable the screensaver...)

Guys, if I've got access to your computer, and it's running, I've got access to everything. Not much is going to change that.

Even if it's not running and the drive is encrypted... Most of the people out there will choose passwords like SECRET and LOVE. Half of the world has a sub-100 IQ.

Oh, and I seem to remember reading somewhere about how "good" IEEE1394 implementations route DMA through to Virtual-Memory Pages, limiting access appropriately at a slight performance cost.

Hmm. Then again, on the other hand, this has some real potential for cheating at World-of-Warcraft....

"Guys, if I've got access to your computer, and it's running, I've got access to everything. Not much is going to change that."

People keep saying this, and it just isn't true; if the BIOS password is set and the case is alarmed, or if you're being watched, I don't see what you think you're going to do - unless some idiot goes and designs an external port which provides direct access to memory, that is.

Notice the attacker doesn't have to wander up to your computer and connect it to their computer, then sit there typing away and cackling evily. All they need to do is get you to plug some trojaned device into your firewire or USB port.

Anyone for a Trojan Mouse? Or a USB flash drive given away by a tech vendor at a conference - beware of geeks bearing gifts.

Here's an interesting possibility for locking your laptop when you leave it: Blue Lock (currently Windows-only). The config file allows you to run programs when locking, these could include dismounting any TrueCrypt partitions, which would remove the key from RAM. So if you had a WDE-laptop AND also a separately encrypted partition on which all your critical data were stored, you could walk away knowing even the FireWire and RAM-freezing hacks wouldn't get you.

-----------------------------------
Blue Lock is an application that locks your Windows PC if a particular Bluetooth device is not detected. For example, if you register your Bluetooth mobile phone with the program but then move away from your desk, the program will detect your phone is out of range and automatically lock your system, requiring the password to be entered to reactivate the system. Full Delphi source code is provided. Download Blue Lock and source here.

...

Configuration: It is possible to reconfigure the default settings by editing bluelock.conf, see the comments in the file for details.

Blue Lock can also be configured to launch an external program when it locks your system, e.g. to delete those incriminating files ;-) ... simply edit the property launchOnLock in bluelock.conf.
-------------------------------------
Details here:
http://members.lycos.co.uk/wuul/bluelock/readme.html

Chris Adams:
I believe various IP attacks (ex: Ping of Death, Teardrop, etc.) were all discovered in various UNIX OSs LONG before MS Addressed them. I'm not sure, but perhaps even before MS even thought of Windows.

Ms lagging behind on known security exploits is nothing new. Nothing new to see here, move along. ;)

full disk encryption is good, even better when you have a yard full of geese and llama to alert you of trespassers, a crocodile in the moat, ankle biting dogs in the house to delay the intruders, a properly sealed cpu room, a security system which shuts down the cpus upon detection of the physical environment its housed in being intruded upon, and on and on.. by the time the intruders get through layer after layer of security, i bet those encryption keys are gone from memory.

The real lesson here is to set up as many roadblocks as possible before the intruder can even get to the cpus.

Disabling the firewire port (if you don't need it) seems like a reasonable suggestion to defeat this particular attack vector.

That's in addition to the other good security practices like FDE (for offline attacks), NX/XD+AV+limited user accounts+disabling unneeded services+firewalls+... for online attacks.

I agree with Brian C that FDE isn't "magic pixie dust," so an attack vector (in this case, an "online attack" vector) that "defeats FDE" doesn't mean FDE isn't useful. Just means that the attacker is forced to resort to another method of attack that, potentially, requires greater skill or luck.

I don't see why this should be contained to FireWire exclusively. Both USB and ESATA support DMA.

What I think would be interesting if someone created a fake ATA (or SATA) device that acquired DMA access then generated a virtual file system that gave the user access to the memory as if they were flat files. There are lots of ATA (and SATA) to USB and FireWire bridge devices out there. If you did it with ATA (IDE) then the production costs should be pretty cheap considering the general availability of IDE parts. Then if you integrated into it a flash drive, you could copy the systems memory to it.

As an information security professional, I'm more worried about the security of other people's data than my own. I take measures similar to those that Bruce has described in previous blogs. However, when I heard about the Princeton study on defeating WDE, I disabled the hibernate function on my laptop and make sure to shut it down when its unattended. This being said, I also have a long complex password protecting the encrypted system.

The point that I'm trying to make is that vulnerabilities like this and the WDE attack highlight the importance of constantly reevaluating the assumptions upon which we base our thinking about security. As new attack vectors appear, old assumptions are invalidated and practices need to be adjusted to remain effective. How many people still think an 8 character complex password is still secure on a windows box? Who thinks its safe to travel with a WDE laptop in hibernate mode? These practices were previously thought to be reasonably safe but I think its safe to assume that they are still required or allowed by the vast majority of corporate security standards.

@Mark:

Generally you can't remove the key from the running machine because the key is used every time you access your encrypted disk (i.e. every time a sector is read or written, the key is used to encrypt or decrypt it).

If you stand up from the machine to go grab a beer from the fridge, you can't temporarily "remove" the encryption key without also preventing ALL disk access to the encrypted partition until the key is restored. Also, it has to be in RAM to be fast enough for use, anyway.

I don't think there's really any solution to this problem other than to not have any Firewire ports in the machine and not ever allow the machine to be physically accessed by an attacker. (good luck.)

If this attack works on USB as well as Firewire - wouldn't it work on wireless USB? Wow, that's some excitement waiting to happen!

painful...it's just sometimes painful to see how little bruce knows about the real world. "Whuzza?! D.M.A. attacks you say?! Well yer darn tootin' I'ma gonna blog dat!"

I'm starting to think you are just posting stuff you don't know anything about, saying it's good or bad (doesn't matter which), and then sifting through the replies to find out if you were right or not.

Removable smart cards, hardware encrypted USB flash drives, and built-in finger print readers all provide two important things: Removable secure "key" storage AND the ability to be unlocked independent of a host PC's software.

So even if someone had your hibernating laptop & your "token" they would have to break the weakest link: the protection on the token. If the token simply stores a certificate or key data in the clear, having it is enough to get in so you'd have to separate the two; Further, with token secured using strong passphrase and/or biometrics, even if laptop & token were stolen together you're damn well protected at the front door asuming no exploit.

Bottom line is what's need is support from the OS. Ultimately to defeat RAM sniffing attacks you're talking hardware FDE (think IronKey but for HDD/SSD) combined with it's keys securely stored on removable drive. 100% Hardware solution = no keys in memory.

Removable smart cards, hardware encrypted USB flash drives, and built-in finger print readers all provide two important things: Removable secure "key" storage AND the ability to be unlocked independent of a host PC's software.

So even if someone had your hibernating laptop & your "token" they would have to break the weakest link: the protection on the token. If the token simply stores a certificate or key data in the clear, having it is enough to get in so you'd have to separate the two; Further, with token secured using strong passphrase and/or biometrics, even if laptop & token were stolen together you're damn well protected at the front door asuming no exploit.

Bottom line is what's need is support from the OS. Ultimately to defeat RAM sniffing attacks you're talking hardware FDE (think IronKey but for HDD/SSD) combined with it's keys securely stored on removable drive. 100% Hardware solution = no keys in memory.

On the Mac OSX platform, setting an Open Firmware password may increase the security of the FireWire interface.

http://matt.ucc.asn.au/apple/

You can always disable the Firewire port when not in use. Nonetheless, as someone who pretends to care for security, Microsoft could have done more, although it's not their "fault".

http://www.hbarel.com/Blog/entry0023.html

BitLocker in advanced modes, with hibernate, will protect against this attack, as well as against RAM freezing attacks.

However if they have access to your machine when it's up and running, then this should work.

It won't, however, work across re-boots, as reading RAM won't get you the second factor needed.

@Todd Knarr and Harry Johnston

Perhaps it'd be helpful to watch a pickpocket, then? Bob Arno is a white hat pickpocket.

http://www.youtube.com/watch?v=W1_BpNAeeX0
http://www.youtube.com/watch?v=hboPd9GzJxg

It's very possible to have unnoticed physical access if you're in public. Perhaps the attacker accidentally spills a drink on you, and while he's helping clean up the mess and drawing attention to drenched trousers and lifting up the laptop to make sure there's no liquid underneath, your eyes won't be on that USB port for a good half a minute.

And then they're asking me 'Why have you disabled firewire port on my PC?' Oh, boy... There are situations when you can't say 'no, thanks' to a potential attacker as you can't foresee if he will try to connect a firewire HDD to the laptop right now, the day after tomorrow or next month. You either put a control on it or you don't do anything and live with the fear that sometimes a serious data loss may happen in your company. It may sound strange in my practice that administrators don't worry about port security because they think it's impossible to implement such a protection without having a special knowledge in that. Of course all of us do some special security audits on occasion. But the question is - should you do a device security audit trail on a regular basis or not? I used to think that's impossible to lockdown devices in Windows. I thought I had to have linux to manage devices that easy. Sure, every PC has a BIOS and disabling device - no more than selecting "Disabled" next to device control options. But then you have to password your BIOS to prevent users from changing the device settings back. However having a password set on user computer BIOS just adds pressure on your support team and nothing more. Remember the old trick with resetting BIOS http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=156 some of us used back in the day. It has no real use except for problems with HID devices when you need to have users work with a USB mouse or a USB "whatever" and it doesn't work because USB ports were disabled on a low level. So what do you do then? Go figure! I liked that Vista is much improved with its device management policies and special administrative templates for playing around with device security with removable storage protection. And still that wasn't the best-fit solution for me (though it obviously holds some value). That's mostly because of the poor management facilities that did not allow me to configure flexible rules to filter out all but some very concrete types of devices from use. Secondly, this solution doesn't provide reliable tracing and reporting which makes it impossible to maintain within changing environments. I am not saying that it's an easy task to do that in Windows. But despite all my fears and delusions I've finally found an elegant solution that allowed me to fine-tune device security throughout my domain. The answer was a desktop management solution. In my case, I found that was Scriptlogic's Desktop Authority. I loved it for its broad device type support http://www.scriptlogic.com/desktop-authority-usb-device-lockdown.asp , ease of device access permission management and powerful reporting. The good thing about it was that I could specify a needed level of access depending on the user, some Active Directory properties associated with the user (such as user membership) and hardware class. The last thing really helps with managing laptops. You know that's so hard to manage laptops nowadays - they are so feature-packed so you often get stuck when it turns that you can't turn the Firewire off forever. When this is a general Firewire fault intrinsic to any Firewire bus version I believe that it also affects Vista machines too, right? Often it's hard to implement device access permissions even though those are deemed easy. In Vista and the new Server you have one set of administrative templates. For Windows XP you don't even have a factory made template so you have either create your own administrative template to stop device drivers or you live with that well-known KB allowing to import the scant ADM file targeting to disable access for USB/CD/Floppy. No-no…There is no doubt in my mind thaqt I was absolutely right that I insisted on purchasing Desktop Authority. The thing that I love in Desktop Authority is the extensive reporting. Its far beyond my home-made reporting scripts that I used to create myself in my 'former administrative life'. Talking about USB security, I really like the report that collects the information for who was logged in when and which USB device he or she tried to plug in to which computer. That's more than that log parsing that I did before. I think when you deal with Active Directory environments or any other complex environments you have to take control on the situation for every computer and every user registered within the directory services you can't manage the whole thing with a per-machine handling. I am glad that I am not alone here and there are companies that make tools like Desktop Authority allowing me as administrator perform a complicated real-time control with SQL reporting without needing to rack my brains on how to solve the problem for each particular user. Why do I need to learn commands for devcon play with device classes, edit ACL for INF files when I can just configure it easier then it takes me configure password security policy in GPMC? So the adage 'The more security you have the more work there will be' doesn't apply here. The thing is 'ease of use'. Why do I care about complexity of rules when it's easy for me to lockdown device access?
You guys here are security-pros and would really love to hear from you. What's your practice in implementing device security in your Windows networks?

For some reason - keyboard lockdown I wonder - the Name/Address fields were cleaned out in the upper post. So just to get others less confused in case they'd decide to continue this conversation.
Thanks guys for this great talk!