Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't think thats the right attitude. There's a difference between being able to open a machine to install malicious hardware / steal hdd's or just plugging in a generic USB stick to pawn it.

I know some of you might argue that even generic USB sticks can do damage and, whilst I agree, this attack is still a degree worse than most of those.

Thus far the most damage an unknown USB stick could do was type commands as a fake keyboard (visible to user) or exploit a driver vulnerability to silently cause mischief.

Correct me if I'm wrong, but those cases could still be trivially stopped by a security policy set by administrators disallowing unknown USB devices. (Of course, how many places would use this is another matter, but it's still very important for places where this does matter.)

This attack on the other hand would seem to be able to completely bypass your operating systems restrictions on USB ports.



From a technical perspective there is a difference now that this is public, but from a security stance, physical access is physical access.

Why? Security knows there are always bugs in software, and assumes they exist. Thanks to @h0t_max, the rest of us know this particular bug exists, but this bug has been around for a while - who's to say evil hax0rs didn't find this bug years ago and have been exploiting it since?

Or put another way - you say an unknown USB stick could exploit a driver vulnerability to silently cause mischief, and then claim that this is easily stopped if an administrator sets a security policy to disallow unknown USB devices. (I assume you mean a Windows GPO enforced policy or similar, and not a written social policy.) Who's to say the code that enforces the policy doesn't have bugs that's exploitable? What if the driver for a known USB stick has exploits?

Physical access is physical access, and while there are mitigations for the evil maid attack (like an encrypted drive and shutting down -not just suspending, when the machine is out of sight), there simply is no way around the fact that physical access is game over.


> while there are mitigations for the evil maid attack (like an encrypted drive and shutting down -not just suspending, when the machine is out of sight),

That mitigation is useless against Evil Maid. There are much more sophisticated mitigations (using a TPM to measure the boot, and then do something akin to TOTP in order to allow the user to actually verify the state of the machine) which actually could protect against Evil Maid almost completely (assuming you don't have something like Intel ME that cannot be verified by the TPM).

"Once you have physical access it's game over" is a very common response to these discussions, and I find it incredibly defeatist. Of course physical access means that the "clock is ticking" until your data is compromised, but sufficient protections can dampen the impact or increase the difficulty.

For example: IOMMU protects against DMA-based attacks, something that was impossible to protect against several years ago. This doesn't mean that someone cannot launch other attacks, but it does mean that the trivial "just plug anything into a USB port and you have DMA" attack is no longer possible.


Evil Maid refers to the broad spectrum of attacks a hypothetical maid could do with physical access and ranges from a drug addict simply looking to resell the laptop at a pawn shop, to a CIA agent, and not being defeatist involves differentiating between their objectives and capabilities in order to make a sensible decision.

Encrypted drive + shutdown is a defense against a specific Evil Maid attack, cold boot attacks. It is not a very expensive attack to run; for the cost of a can of compressed air, and a USB drive, anybody sophisticated can run this attack. https://en.wikipedia.org/wiki/Cold_boot_attack

Sorry to sound defeatist, but if you had been relying on IOMMU to save you, the trivial "plug anything into a USB port and you have CPU JTAG access" attack has always been possible. (Never mind that IOMMU implementations aren't guaranteed to be bug free.)

In the face of that, what do you do?

With this knowledge, all I really can do is stay up to date and patch-patch-patch. Have a travel Chromebook for leaving in hotel rooms, but ultimately I just have to know that it's not enough, especially against a CIA-grade Evil Maid, or an Evil Maid that's able to factor 4096-bit prime numbers. (That last one's not theoretical, either. It was revealed a few weeks ago that TPMs in Chromebooks and other hardware was generating weak keys, leading to cloud-factorable 4096-bit RSA keys.)

A less-sophisticated Evil Maid can still physically steal my laptop for pawning, and even if they can't get my data, I've still had my laptop stolen. Not-being-defeatist, I backup my data, although that has a totally different set of security concerns over the Internet.


The TPM is actually implemented as an Intel ME applet on a lot of PCs... >.<


Right, but there is a TPM pin-out standard -- so theoretically you could swap out the TPM of any device (which has a physical TPM obviously) with any other manufacturer's TPM and it would still "just work". While it might be implemented in Intel ME, there are a lot of laptops that have physical TPM chips.


Some manufacturers just don't pay more for an LPC or SPI-based TPM, and just use the fTPM one running as an ME applet (my Kaby Lake laptop does this)


> From a technical perspective there is a difference now that this is public, but from a security stance, physical access is physical access.

Access to a USB port is not physical access. USB is a network interface that is commonly used to connect host computers to small portable embedded systems, often tiny NAS units of other people also known as USB flash drives.


Yes, it's just like the example in the first season of House of Cards, where the journalist for some reason is conned into putting the USB into a server. That plot was really stretching to find a way to kill off a good character but still it shows how a "guest" could try to discreetly manipulate a system.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: