Why the Security of USB Is Fundamentally Broken
August 11, 2014 10:57 PM Subscribe
Computer users pass around USB sticks like silicon business cards. Although we know they often carry malware infections, we depend on antivirus scans and the occasional reformatting to keep our thumbdrives from becoming the carrier for the next digital epidemic. But the security problems with USB devices run deeper than you think: Their risk isn't just in what they carry, it's built into the core of how they work.
The article doesn't even bother linking to the BadUSB research, so here it is (pdf).
posted by neckro23 at 12:05 AM on August 12, 2014 [6 favorites]
posted by neckro23 at 12:05 AM on August 12, 2014 [6 favorites]
The "broken" part is how people treat them, and what they assume usb devices are capable of.
Arguably some of that burden falls on the host platform and OS as well. If a person inserts a USB storage device, that person, I suggest, ought to be able to have a reasonable expectation that it will act like a USB storage device and that the host will not support any other interaction.
Admittedly, the "storage device" is perhaps the simplest case to actually implement this kind of security. USB devices can do arbitrary things as their intended purpose, and creating a platform security model that permits only some definition of "safe" interactions given this open set of possibilities would be incredibly challenging to even specify; as for implementing it, hoo boy.
posted by George_Spiggott at 12:13 AM on August 12, 2014 [4 favorites]
Arguably some of that burden falls on the host platform and OS as well. If a person inserts a USB storage device, that person, I suggest, ought to be able to have a reasonable expectation that it will act like a USB storage device and that the host will not support any other interaction.
Admittedly, the "storage device" is perhaps the simplest case to actually implement this kind of security. USB devices can do arbitrary things as their intended purpose, and creating a platform security model that permits only some definition of "safe" interactions given this open set of possibilities would be incredibly challenging to even specify; as for implementing it, hoo boy.
posted by George_Spiggott at 12:13 AM on August 12, 2014 [4 favorites]
What does one do against "we hacked the basic firmware of this category of device so it does bad things" sorts of attacks? Where does one even find a firewall against that? Given the revelations about what the NSA has been up to, to the point of alleged corrupting of device manufacturers to include backdoors and such?
Basically, nothing can be trusted, ever, no matter what the source? And the more a device is used outside one's private collection of devices (like a USB stick), the less it is to be trusted?
The potential level of paranoia is mammoth.
posted by hippybear at 1:22 AM on August 12, 2014
Basically, nothing can be trusted, ever, no matter what the source? And the more a device is used outside one's private collection of devices (like a USB stick), the less it is to be trusted?
The potential level of paranoia is mammoth.
posted by hippybear at 1:22 AM on August 12, 2014
If this is seen as a serious threat by the operating system vendors, there's quite a lot they could do to deal with it. Asking the user what category of device they expect something to be after the plug it in and before you load any drivers for it would more-or-less eliminate the "fake keyboard" or "fake network adapter" issue (although admittedly you'd have to trust the first keyboard, otherwise the user wouldn't be able to provide input to accept it in the first place). Dealing with malicious USB drive firmware modifying files as they're copied to your computer would be harder, and probably quite implementation specific.
Ultimately, if you want USB to allow you to plug in keyboards, mice, network adapters, storage devices and random widgets you *need* to have a certain level of device trust. This is one of those cases where security directly counters utility. There has to be a tradeoff somewhere. Fortunately the effort required to exploit any of these issues is quite high, and so it's likely to only be used in a targeted attack. Hopefully if you're likely to be the target of a sophisticated USB based attack you're already aware of that fact and so take precautions like not allowing unknown devices on your systems.
posted by leo_r at 1:55 AM on August 12, 2014 [1 favorite]
Ultimately, if you want USB to allow you to plug in keyboards, mice, network adapters, storage devices and random widgets you *need* to have a certain level of device trust. This is one of those cases where security directly counters utility. There has to be a tradeoff somewhere. Fortunately the effort required to exploit any of these issues is quite high, and so it's likely to only be used in a targeted attack. Hopefully if you're likely to be the target of a sophisticated USB based attack you're already aware of that fact and so take precautions like not allowing unknown devices on your systems.
posted by leo_r at 1:55 AM on August 12, 2014 [1 favorite]
Here is the fix for this "fundamentally broken" standard:
If a usb keyboard is already connected to the computer, don't let a second one work as a keyboard.
Ta da! Breakage averted.
posted by devnull at 2:21 AM on August 12, 2014
If a usb keyboard is already connected to the computer, don't let a second one work as a keyboard.
Ta da! Breakage averted.
posted by devnull at 2:21 AM on August 12, 2014
But people use multiple keyboards on their computer all the time. (Ever docked a laptop?)
posted by ryanrs at 3:12 AM on August 12, 2014 [7 favorites]
posted by ryanrs at 3:12 AM on August 12, 2014 [7 favorites]
There are three levels to which computer users appear to trust USB devices:
1. A belief that anything which can be plugged into a USB device, and which seems to work, is non-problematic. This is the stance that the vast majority seem to take.
2. A specific distrust of certain USB storage devices which have been plugged into dodgy computers; all others are OK. This would appear to be the stance of the minority who are somewhat aware of security issues.
3. A distrust of any USB device at all - even a non storage one - as either a device on which a viral infection may be invisibly acquired or as one in which ones own invisible infection may be invisibly passed to others.
The article implies that the third level of trust is the one that should be adopted by anybody who care about the security of what is on their computers. The fact that the vast majority of people are completely unaware of this is a major problem.
posted by rongorongo at 3:20 AM on August 12, 2014 [1 favorite]
1. A belief that anything which can be plugged into a USB device, and which seems to work, is non-problematic. This is the stance that the vast majority seem to take.
2. A specific distrust of certain USB storage devices which have been plugged into dodgy computers; all others are OK. This would appear to be the stance of the minority who are somewhat aware of security issues.
3. A distrust of any USB device at all - even a non storage one - as either a device on which a viral infection may be invisibly acquired or as one in which ones own invisible infection may be invisibly passed to others.
The article implies that the third level of trust is the one that should be adopted by anybody who care about the security of what is on their computers. The fact that the vast majority of people are completely unaware of this is a major problem.
posted by rongorongo at 3:20 AM on August 12, 2014 [1 favorite]
I'd never thought about the "everything's on the bus, devices can listen to each others' activity if they're connected to the same controller" thing.
Would that be something that could be addressed by PKE? The driver has the public key, the device has the private key, so the host system would have to be compromised in order to monitor the interactions with that device? (actually, I guess it would work with a shared key, too... the only requirement is that the key never be sent over the bus so the driver and the device would have to be hardcoded with it).
I'm smart enough to know I'm not smart enough to come up with solutions to security problems. Is there something about the above that wouldn't work? Would the computational overhead or latency be too great?
posted by Riki tiki at 3:38 AM on August 12, 2014
Would that be something that could be addressed by PKE? The driver has the public key, the device has the private key, so the host system would have to be compromised in order to monitor the interactions with that device? (actually, I guess it would work with a shared key, too... the only requirement is that the key never be sent over the bus so the driver and the device would have to be hardcoded with it).
I'm smart enough to know I'm not smart enough to come up with solutions to security problems. Is there something about the above that wouldn't work? Would the computational overhead or latency be too great?
posted by Riki tiki at 3:38 AM on August 12, 2014
If you want to play with these kinds of exploits yourself, build a Facedancer board. Then you can make your computer act as a USB device, with a convenient Python API. Make your computer talk to itself over USB.
posted by sixohsix at 3:44 AM on August 12, 2014 [5 favorites]
posted by sixohsix at 3:44 AM on August 12, 2014 [5 favorites]
How does the driver learn of these keys? If you get the key from the device itself, how does that tell you if the device is hostile? Which driver, exactly, is talking USB when your computer is booting form your USB hard drive?
I'm not saying there aren't decent answers to these questions. But thinking about them makes the difficulty a little more clear.
posted by ryanrs at 3:45 AM on August 12, 2014 [1 favorite]
I'm not saying there aren't decent answers to these questions. But thinking about them makes the difficulty a little more clear.
posted by ryanrs at 3:45 AM on August 12, 2014 [1 favorite]
But people use multiple keyboards on their computer all the time.
And sometimes multiple people use the same keyboard.
posted by Mr. Bad Example at 4:09 AM on August 12, 2014 [4 favorites]
And sometimes multiple people use the same keyboard.
posted by Mr. Bad Example at 4:09 AM on August 12, 2014 [4 favorites]
Basically the entire technology stack of modern computing infrastructure is insecure down to the metal and up to Adobe Reader, between malice and security-naive-designs.
It's probably going to turn into a problem here soon.
posted by PMdixon at 4:10 AM on August 12, 2014 [4 favorites]
It's probably going to turn into a problem here soon.
posted by PMdixon at 4:10 AM on August 12, 2014 [4 favorites]
> It's probably going to turn into a problem here soon.
"You can't trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code." -- Ken Thompson, "Reflections on Trusting Trust," 1984.
posted by ardgedee at 4:20 AM on August 12, 2014
"You can't trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code." -- Ken Thompson, "Reflections on Trusting Trust," 1984.
posted by ardgedee at 4:20 AM on August 12, 2014
Appelbaum's final 30c3 talk To Protect And Infect, Part 2 discussed Cottonmouth the day Der Spiegel announced it (previously) is basically a giant To Hack list around NSA does, while Claudio Guarnieri and Morgan Marquis-Boire's 30c3 talk To Protect and Infect [Part 1] (previously) sketches what hackers have already done to mitigate the commercial intrusion tools about which they'd previously known. In USB's case I guess the best mitigation is simply warning people.
posted by jeffburdges at 4:33 AM on August 12, 2014
posted by jeffburdges at 4:33 AM on August 12, 2014
As someone who lived through the great email attachment scourge of 1998, warning people will not be enough.
posted by empath at 4:43 AM on August 12, 2014 [2 favorites]
posted by empath at 4:43 AM on August 12, 2014 [2 favorites]
As someone who lived through the great email attachment scourge of 1998, warning people will not be enough.
Historical note: it was one of my exes who discovered Concept, the first email attachment virus. She had no end of trouble convincing even fellow AV experts such a thing was possible.
posted by scalefree at 4:56 AM on August 12, 2014 [3 favorites]
Historical note: it was one of my exes who discovered Concept, the first email attachment virus. She had no end of trouble convincing even fellow AV experts such a thing was possible.
posted by scalefree at 4:56 AM on August 12, 2014 [3 favorites]
it was one of my exes
heh
posted by paleyellowwithorange at 5:01 AM on August 12, 2014 [21 favorites]
heh
posted by paleyellowwithorange at 5:01 AM on August 12, 2014 [21 favorites]
The security of USB is not fundamentally broken. The security of DMA enabled peripherals (such as Firewire, PCMCIA, and lightning bolt) are fundamentally broken, but USB doesn't have DMA.
USB actually speaks SCSI, for those who remember SCSI.
posted by scalefree at 5:03 AM on August 12, 2014 [1 favorite]
USB actually speaks SCSI, for those who remember SCSI.
posted by scalefree at 5:03 AM on August 12, 2014 [1 favorite]
it was one of my exes
Alright, I'll narrow it down. One of the famous ones.
posted by scalefree at 5:04 AM on August 12, 2014 [2 favorites]
Alright, I'll narrow it down. One of the famous ones.
posted by scalefree at 5:04 AM on August 12, 2014 [2 favorites]
I think the joke was ".exe's", rather than that you've had multiple exes...
posted by benzo8 at 5:08 AM on August 12, 2014 [15 favorites]
posted by benzo8 at 5:08 AM on August 12, 2014 [15 favorites]
The solution is simple:
"You've just inserted a USB device. Do you want to allow it to act as a [storage device] for the current session.?" Yes/No
Basically the same as the security prompts on iOS and Android, but every time you plug it in, managed by the O/S.
posted by blue_beetle at 5:12 AM on August 12, 2014
"You've just inserted a USB device. Do you want to allow it to act as a [storage device] for the current session.?" Yes/No
Basically the same as the security prompts on iOS and Android, but every time you plug it in, managed by the O/S.
posted by blue_beetle at 5:12 AM on August 12, 2014
i don't get the difficulty in convincing manufacturers.
"Hey USB can do XYZ now."
"No. It can't."
"Really? Let me borrow your laptop."
posted by oddman at 5:14 AM on August 12, 2014 [1 favorite]
"Hey USB can do XYZ now."
"No. It can't."
"Really? Let me borrow your laptop."
posted by oddman at 5:14 AM on August 12, 2014 [1 favorite]
Bahrain government hacked lawyers and activists with UK-German spyware (via the Intercept article)
posted by jeffburdges at 5:18 AM on August 12, 2014
posted by jeffburdges at 5:18 AM on August 12, 2014
yeahwhatever: your comment is a great example of a prevalent attitude which holds back the security community. Yes, the problem isn't the USB protocol itself and, yes, it's not the first time we've heard of this class of attack but don't let the allure of internet pedant points prevent you from realizing that your comment is as useful as telling people not to open attachments. From the perspective of someone using a computer, even someone with above-average security awareness, the problem is that you cannot tell what will happen when you connect a USB peripheral to the system and *everything* has been designed under the mistaken belief that USB devices are dumb peripherals rather than peer computers.
You're almost certainly wrong that this is something everyone at BlackHat already knew and definitely wrong to dismiss its impact because even within the community of people who were fully aware of this problem, almost nobody routinely takes the kinds of precautions necessary to safely use arbitrary USB devices (i.e. use an untrusted throwaway device to copy the files to a network location for inspection and transfer to the computer you actually use). That's something which will require low-level OS changes and a bunch of new UI, which is expensive and thus unlikely to happen without more public awareness that the current model is unsustainable.
I've known about this class of problem since 2003 when that Mac Hack exploit raised the red flag about Firewire. This article marks the first time I've ever had a user ask whether there was any way to safely access an unknown USB device. The answer, of course, is “no” and no amount of inappropriately-smug “nothing to see here, move along” dismissal will make that problem less intractable in practice, any more than telling people not to open attachments is helpful security advice.
posted by adamsc at 5:28 AM on August 12, 2014 [16 favorites]
You're almost certainly wrong that this is something everyone at BlackHat already knew and definitely wrong to dismiss its impact because even within the community of people who were fully aware of this problem, almost nobody routinely takes the kinds of precautions necessary to safely use arbitrary USB devices (i.e. use an untrusted throwaway device to copy the files to a network location for inspection and transfer to the computer you actually use). That's something which will require low-level OS changes and a bunch of new UI, which is expensive and thus unlikely to happen without more public awareness that the current model is unsustainable.
I've known about this class of problem since 2003 when that Mac Hack exploit raised the red flag about Firewire. This article marks the first time I've ever had a user ask whether there was any way to safely access an unknown USB device. The answer, of course, is “no” and no amount of inappropriately-smug “nothing to see here, move along” dismissal will make that problem less intractable in practice, any more than telling people not to open attachments is helpful security advice.
posted by adamsc at 5:28 AM on August 12, 2014 [16 favorites]
Those who do not remember SCSI are doomed to repeat it.
posted by mikelieman at 5:36 AM on August 12, 2014 [5 favorites]
posted by mikelieman at 5:36 AM on August 12, 2014 [5 favorites]
I've known about this class of problem since 2003 when that Mac Hack exploit raised the red flag about Firewire. This article marks the first time I've ever had a user ask whether there was any way to safely access an unknown USB device.
Nearly impossible to prove but I figured it out in 2001, extrapolating from the Windows Autorun vulnerabilities, which I was also first with. I was just too lazy to follow through with either one. Such is life.
posted by scalefree at 6:11 AM on August 12, 2014
Nearly impossible to prove but I figured it out in 2001, extrapolating from the Windows Autorun vulnerabilities, which I was also first with. I was just too lazy to follow through with either one. Such is life.
posted by scalefree at 6:11 AM on August 12, 2014
adamsc: yeahwhatever was not, as I read it, being dismissive of the problem; he was being dismissive of the journalism which we can all agree is shitty. If the headline is "Why the Security of USB is Fundamentally Broken" and a) the security of USB is not fundamentally broken and b) the article does a terrible job of explaining what the actual problem is in favor of fearmongering, there's a problem. There's plenty you can do at the OS level to defang these attacks, and it's not easy to infect a random thumbdrive or whatever.
(caveat: I know jack about USB3 so it's possible/probably there's a new class of attacks there, but that's not what this article appears to be talking about.)
posted by phooky at 6:50 AM on August 12, 2014 [1 favorite]
(caveat: I know jack about USB3 so it's possible/probably there's a new class of attacks there, but that's not what this article appears to be talking about.)
posted by phooky at 6:50 AM on August 12, 2014 [1 favorite]
Windows already asks the user, in some circumstances, what to do with some random device you've plugged into the host computer. (For instance, if you plug in a digital camera, you'll get prompted to either open it as a storage device with Windows Explorer, or view the photos in some other program, etc.)
It seems like that's the easiest solution to this problem. There is no way for the host system to know, a priori, whether the user has connected a simple USB mass storage stick that is maliciously posing as a keyboard or network adaptor, or if they've really plugged in a second keyboard or network adaptor. So...ask. Or rather, assume the safe case (mass storage) by default, and ask in some not face-slappingly intrusive way whether that's correct. If it's actually not mass storage, then you can go ahead and load it up.
Sure, you could still muck with the firmware on the USB stick's controller. But the interesting aspects of the attack are almost all around having the USB stick do things that a mass storage device shouldn't do (e.g. intercept network traffic, type commands into the host system). So that would fix the biggest issues.
You are never going to get around the fact that a USB stick is some memory coupled to a controller, and the controller runs firmware which can be replaced with hostile code. Same with hard drives (they have controllers too, and we know now that the NSA messes with them) and even SD cards. There is no easy fix there.
But you can at least ensure that the cards always act like data storage. Albeit untrustworthy data storage—the stick can alter data stored there, misreport what it contains, etc.—but it shouldn't be able to "take over" a PC. That's just shitty implementation on the part of the host machine.
posted by Kadin2048 at 6:51 AM on August 12, 2014
It seems like that's the easiest solution to this problem. There is no way for the host system to know, a priori, whether the user has connected a simple USB mass storage stick that is maliciously posing as a keyboard or network adaptor, or if they've really plugged in a second keyboard or network adaptor. So...ask. Or rather, assume the safe case (mass storage) by default, and ask in some not face-slappingly intrusive way whether that's correct. If it's actually not mass storage, then you can go ahead and load it up.
Sure, you could still muck with the firmware on the USB stick's controller. But the interesting aspects of the attack are almost all around having the USB stick do things that a mass storage device shouldn't do (e.g. intercept network traffic, type commands into the host system). So that would fix the biggest issues.
You are never going to get around the fact that a USB stick is some memory coupled to a controller, and the controller runs firmware which can be replaced with hostile code. Same with hard drives (they have controllers too, and we know now that the NSA messes with them) and even SD cards. There is no easy fix there.
But you can at least ensure that the cards always act like data storage. Albeit untrustworthy data storage—the stick can alter data stored there, misreport what it contains, etc.—but it shouldn't be able to "take over" a PC. That's just shitty implementation on the part of the host machine.
posted by Kadin2048 at 6:51 AM on August 12, 2014
Also seconding sixohsix's recommendation for a Facedancer board with the caveat that it's really, really difficult for an amateur to assemble; if you're not a soldering master try to find one preassembled or have a wizard help you.
posted by phooky at 6:57 AM on August 12, 2014
posted by phooky at 6:57 AM on August 12, 2014
A modern computer is really a network of computers talking to each other, all running different firmwares: disks, network controllers, IO controllers, video cards, etc. And then we connect them to other computers, like displays, mice, keyboards, etc.
The firmware of any of those computers could either: 1) be tampered with or created by a malicious entity or 2) contain a vulnerability giving an attacker access to that computer. In both cases, you are Very Screwed. For instance, if there's a vulnerability in my network interface, an attacker could control my network traffic just like if it was controlled the wireless access point I'm connected to.
It's quite a difficult problem to solve, because our current hardware and software isn't built to deal with it. The solutions might indeed involve crypto with devices/firmwares being authenticated by a trusted core, like a TPM (but there are issues with TPM).
posted by Monday, stony Monday at 7:06 AM on August 12, 2014 [2 favorites]
The firmware of any of those computers could either: 1) be tampered with or created by a malicious entity or 2) contain a vulnerability giving an attacker access to that computer. In both cases, you are Very Screwed. For instance, if there's a vulnerability in my network interface, an attacker could control my network traffic just like if it was controlled the wireless access point I'm connected to.
It's quite a difficult problem to solve, because our current hardware and software isn't built to deal with it. The solutions might indeed involve crypto with devices/firmwares being authenticated by a trusted core, like a TPM (but there are issues with TPM).
posted by Monday, stony Monday at 7:06 AM on August 12, 2014 [2 favorites]
It's not like the smart people who engineer these things haven't thought of this.
However, there aren't many good options for providing security at the physical level. If an attacker has access to your machine, you're pwned, and there isn't much that you can do about that.
posted by schmod at 7:08 AM on August 12, 2014 [1 favorite]
However, there aren't many good options for providing security at the physical level. If an attacker has access to your machine, you're pwned, and there isn't much that you can do about that.
posted by schmod at 7:08 AM on August 12, 2014 [1 favorite]
USB actually speaks SCSI, for those who remember SCSI.
Well of course I remember SCSI.
USB speaks SCSI, in particular, UAS-2 (USB Attached SCSI-2).
Those who do not remember SCSI are doomed to repeat it.
We did.
SAS uses SCSI (obviously, since it's Serial Attached SCSI) and Fiber Channel is SCSI over a different wire protocol, and IEEE1394 (Firewire) is SCSI over Yet Another Wire Protocol.
Heck, we put SCSI into IP packets. (iSCSI and SRP)
Anymore, there are exactly two command sets controlling storage -- ATA (AT Attachment) and SCSI. They're implemented over dozens of interfaces, but the command sets are basically those two. Indeed, we have ATAPI, the ATA Peripheral Interface, which is fundamentally SCSI over ATA (this is how your ATA optical disks work.)
ATA lives on thanks to SATA and flash memory cards. Everything else is SCSI. Indeed, we have ATAPI, the ATA Peripheral Interface, which is fundamentally SCSI over ATA (this is how your ATA optical disks work.)
posted by eriko at 7:08 AM on August 12, 2014 [7 favorites]
Well of course I remember SCSI.
USB speaks SCSI, in particular, UAS-2 (USB Attached SCSI-2).
Those who do not remember SCSI are doomed to repeat it.
We did.
SAS uses SCSI (obviously, since it's Serial Attached SCSI) and Fiber Channel is SCSI over a different wire protocol, and IEEE1394 (Firewire) is SCSI over Yet Another Wire Protocol.
Heck, we put SCSI into IP packets. (iSCSI and SRP)
Anymore, there are exactly two command sets controlling storage -- ATA (AT Attachment) and SCSI. They're implemented over dozens of interfaces, but the command sets are basically those two. Indeed, we have ATAPI, the ATA Peripheral Interface, which is fundamentally SCSI over ATA (this is how your ATA optical disks work.)
ATA lives on thanks to SATA and flash memory cards. Everything else is SCSI. Indeed, we have ATAPI, the ATA Peripheral Interface, which is fundamentally SCSI over ATA (this is how your ATA optical disks work.)
posted by eriko at 7:08 AM on August 12, 2014 [7 favorites]
I don't believe it's really SCSI if you don't have to use a terminator.
posted by rikschell at 7:16 AM on August 12, 2014 [7 favorites]
posted by rikschell at 7:16 AM on August 12, 2014 [7 favorites]
Linux doesn't tend to auto-load usb devices, does it?
Depends on the desktop. XMonad doesn't do anything automatically. IIRC, Gnome and KDE will pop up a dialog when the bus sees a message about a device...
posted by mikelieman at 7:25 AM on August 12, 2014
Depends on the desktop. XMonad doesn't do anything automatically. IIRC, Gnome and KDE will pop up a dialog when the bus sees a message about a device...
posted by mikelieman at 7:25 AM on August 12, 2014
@phooky: my point was that the security of USB is fundamentally broken, just that it's broken in a different place. I think the article did a reasonable job of explaining the problem, albeit suffering from Wired's trademark overdone breathless style, which is that USB devices are computers and can be compromised but for the last couple decades everyone has assumed they're trustworthy.
OS level protections can potentially help a lot but it's still going to require care to avoid simply training everyone to hit okay when the prompt pops up.
posted by adamsc at 7:26 AM on August 12, 2014
OS level protections can potentially help a lot but it's still going to require care to avoid simply training everyone to hit okay when the prompt pops up.
posted by adamsc at 7:26 AM on August 12, 2014
The thing is, can't a plugged in device with a hostile firmware see all the data on a serial line, even if it's messages aren't being interpreted by the host? So the USB storage stick could have a keylogger in the firmware, and record your keystrokes, even if you never mount its storage.
posted by idiopath at 7:34 AM on August 12, 2014
posted by idiopath at 7:34 AM on August 12, 2014
Or a keyboard could have USB storage and WiFi nside and log your key strokes without ever presenting itself as USB storage, though that is almost a completely different sort of problem and Linux et al will mount it happily as a keyboard without prompting.
posted by aydeejones at 7:36 AM on August 12, 2014
posted by aydeejones at 7:36 AM on August 12, 2014
Who routinely drags their keyboard around? Well I bought this fucking sweet logitech keyboard yesterday with a tiny wireless USB wireless transmitter and the keyboard has a built in touch pad device to protect my right arm from RSI. I want to try it at work which is a secure health care environment. Hmmmm. Also I bought a 16GB flash drive that has a micro USB port that plugs right into an android phone. Hmmmm. THANKS OBAMA
posted by aydeejones at 7:41 AM on August 12, 2014
posted by aydeejones at 7:41 AM on August 12, 2014
Linux doesn't tend to auto-load usb devices, does it?
Ubuntu certainly auto-loads HID devices. Hell, these days by default it includes the hotplug system in initramfs, so you can hotplug a keyboard into a headless machine while it's sitting at the initramfs prompt after a failed boot. That's actually proven handy at times.
posted by George_Spiggott at 7:50 AM on August 12, 2014
Ubuntu certainly auto-loads HID devices. Hell, these days by default it includes the hotplug system in initramfs, so you can hotplug a keyboard into a headless machine while it's sitting at the initramfs prompt after a failed boot. That's actually proven handy at times.
posted by George_Spiggott at 7:50 AM on August 12, 2014
BTW, we should make a distinction between activating the device and mounting storage to the filesystem. The way things are now, an OS that pops up a dialog to ask you to confirm that you want to mount the USB disk hasn't saved you from some maybe hypothetical malicious activity; in order to show you that message, the driver had to be loaded and the device accessed by the system. Any evil malware developer will have certainly designed their exploit to have taken off at that level, without relying on the late-stage userspace thing that the OS asked you to confirm you want to do.
posted by George_Spiggott at 8:00 AM on August 12, 2014
posted by George_Spiggott at 8:00 AM on August 12, 2014
in order to show you that message, the driver had to be loaded and the device accessed by the system.
I don't think that's really true. All the host would have to do at that point is enumerate the device, which includes determining its speed, sending a Get_Device_Descriptor command, and then reading the result which includes the device class, subclass, protocol, and other information.
Here's a pretty nice high-level description of USB device enumeration (PDF), for those who are interested.
The enumeration process seems safe, barring some vulnerability in the USB controller itself that would allow it to be hijacked by the device (an entirely different threat scenario than what's being discussed; it's akin to having a rogue packet somehow take over your Ethernet card). The problems begin when the host system starts loading up drivers and interacting with the device at the OS, rather than the USB controller, level.
That's where you could insert some logic to refuse to proceed with driver-loading of certain types of devices, without validation.
Today most PCs go immediately from enumeration of the new device to loading the device's drivers and interacting with it. That's the unsafe behavior. The really stupid behavior is autorun, which is one more step beyond that: not just loading drivers and interacting with the device, but mounting it and then beginning to execute whatever arbitrary code it happens to have stored on it. That's facepalm-level stupid, to the point that not even Microsoft seems to think that it's a good move anymore.
posted by Kadin2048 at 8:30 AM on August 12, 2014
I don't think that's really true. All the host would have to do at that point is enumerate the device, which includes determining its speed, sending a Get_Device_Descriptor command, and then reading the result which includes the device class, subclass, protocol, and other information.
Here's a pretty nice high-level description of USB device enumeration (PDF), for those who are interested.
The enumeration process seems safe, barring some vulnerability in the USB controller itself that would allow it to be hijacked by the device (an entirely different threat scenario than what's being discussed; it's akin to having a rogue packet somehow take over your Ethernet card). The problems begin when the host system starts loading up drivers and interacting with the device at the OS, rather than the USB controller, level.
That's where you could insert some logic to refuse to proceed with driver-loading of certain types of devices, without validation.
Today most PCs go immediately from enumeration of the new device to loading the device's drivers and interacting with it. That's the unsafe behavior. The really stupid behavior is autorun, which is one more step beyond that: not just loading drivers and interacting with the device, but mounting it and then beginning to execute whatever arbitrary code it happens to have stored on it. That's facepalm-level stupid, to the point that not even Microsoft seems to think that it's a good move anymore.
posted by Kadin2048 at 8:30 AM on August 12, 2014
I don't think that's really true. All the host would have to do at that point is enumerate the device
Sure, and that's closer to a more secure ideal than what it does now. As things stand, though, when I attach a USB disk on a Linux system, by the time it prompts me to mount the device (assuming I'm on a relatively "thick" X desktop like Gnome or even LXDE), it has already loaded the driver stack, read the partition table and identified the filesystems on it (I believe beyond simply reading the partition types: in at least some cases it actually scans the file system info), created block devices for all the partitions and attached them to /dev nodes and is simply prompting me to mount them to the filesystem hierarchy at some point where I have permissions.
posted by George_Spiggott at 8:36 AM on August 12, 2014 [1 favorite]
Sure, and that's closer to a more secure ideal than what it does now. As things stand, though, when I attach a USB disk on a Linux system, by the time it prompts me to mount the device (assuming I'm on a relatively "thick" X desktop like Gnome or even LXDE), it has already loaded the driver stack, read the partition table and identified the filesystems on it (I believe beyond simply reading the partition types: in at least some cases it actually scans the file system info), created block devices for all the partitions and attached them to /dev nodes and is simply prompting me to mount them to the filesystem hierarchy at some point where I have permissions.
posted by George_Spiggott at 8:36 AM on August 12, 2014 [1 favorite]
(On rereading your last paragraph, you effectively said as much; pardon the elaboration.)
posted by George_Spiggott at 8:45 AM on August 12, 2014
posted by George_Spiggott at 8:45 AM on August 12, 2014
Surely a naive question that betrays no understanding of the issue, but... I can see why an expensive USB device would have rewritable (hence upgradeable) firmware but why would that be true on ultra cheapie USB thumb drives? Wouldn't they be even cheaper to manufacture if the factory used write-once-and-that's-it-forever PROMs? Does anybody anywhere go around flashing the firmware of the thumb drive they might have paid $10 for but more likely was given to them free by some salesman? Is the flashable firmware thing part of the USB standard, so that if you don't support it you can't call your device USB?
posted by jfuller at 9:14 AM on August 12, 2014
posted by jfuller at 9:14 AM on August 12, 2014
Regarding the question if it's theoretically possible for USB devices to sniff the data that is sent by other USB devices wikipedia has the following to say:
Each hub has exactly one upstream port and a number of downstream ports. The upstream port connects the hub (directly or through other hubs) to the host. Other hubs or devices can be attached to the downstream ports. During normal transmission, hubs are essentially transparent: data received from its upstream port is broadcast to all devices attached to its downstream ports; data received from a downstream port is generally forwarded to the upstream port only. This way, what is sent by the host is received by all hubs and devices, and what sent by a device is received by the host but not by the other devices (an exception is resume signaling).
So one direction of the data flow - from the host (your pc) to the device (USB stick etc.) - could possibly be read by other devices. This wouldn't work in the other direction, for instance with a password entered via an USB keyboard.
There's also a stackexchange question on this subject.
Wouldn't they be even cheaper to manufacture if the factory used write-once-and-that's-it-forever PROMs?
The explanation I've heard/read is that it's cheaper and easier this way for the device manufactures to adapt to different (size) flash chips used. Apparently it's not unusal even for SD cards to come with rewritable firmware.
posted by mirage pine at 9:26 AM on August 12, 2014 [1 favorite]
Each hub has exactly one upstream port and a number of downstream ports. The upstream port connects the hub (directly or through other hubs) to the host. Other hubs or devices can be attached to the downstream ports. During normal transmission, hubs are essentially transparent: data received from its upstream port is broadcast to all devices attached to its downstream ports; data received from a downstream port is generally forwarded to the upstream port only. This way, what is sent by the host is received by all hubs and devices, and what sent by a device is received by the host but not by the other devices (an exception is resume signaling).
So one direction of the data flow - from the host (your pc) to the device (USB stick etc.) - could possibly be read by other devices. This wouldn't work in the other direction, for instance with a password entered via an USB keyboard.
There's also a stackexchange question on this subject.
Wouldn't they be even cheaper to manufacture if the factory used write-once-and-that's-it-forever PROMs?
The explanation I've heard/read is that it's cheaper and easier this way for the device manufactures to adapt to different (size) flash chips used. Apparently it's not unusal even for SD cards to come with rewritable firmware.
posted by mirage pine at 9:26 AM on August 12, 2014 [1 favorite]
As an aside, the default setting on Microsoft's Security Essentials is set to ignore external devices such as USB sticks. Just another example of MS in their pursuit of security.
posted by Gungho at 9:27 AM on August 12, 2014 [1 favorite]
posted by Gungho at 9:27 AM on August 12, 2014 [1 favorite]
The thing is that in a lot of cases, it wouldn't matter, because windows can't see what the firmware is running. The firmware can detect that windows is trying to access it and present itself as a perfectly safe USB drive. Then when you reboot it with the drive still in, it loads an entirely different payload for the bios that loads a rootkit.
posted by empath at 9:32 AM on August 12, 2014 [1 favorite]
posted by empath at 9:32 AM on August 12, 2014 [1 favorite]
As someone who writes embedded code for a living: who would've thought we should've required in the standard that USB device/chipset firmware upgrades require strong encryption and keys not reused across different products. This sort of stuff is software engineering 102. :(
posted by introp at 10:54 AM on August 12, 2014
posted by introp at 10:54 AM on August 12, 2014
As someone who writes embedded code for a living: who would've thought we should've required in the standard that USB device/chipset firmware upgrades require strong encryption and keys not reused across different products. This sort of stuff is software engineering 102. :(
Why allow firmware upgrades at all? It's just a USB stick. Who upgrades their firmware on a USB stick?
It is very simple to prevent in-circuit firmware changes in the hardware design.
posted by JackFlash at 11:17 AM on August 12, 2014
Why allow firmware upgrades at all? It's just a USB stick. Who upgrades their firmware on a USB stick?
It is very simple to prevent in-circuit firmware changes in the hardware design.
posted by JackFlash at 11:17 AM on August 12, 2014
A good point. It's very likely that the controller is likely reused across a lot of products of varying size, capabilities, and other parts. It's a necessary measure to be able to program it at the factory for vendor X flash part or vendor Y flash part based on whoever is cheaper on this month's quote, etc. Someone could burn the programming fuse (not actually a fuse) before they leave the factory, as the first step in the test process for example. It's often hard to choose between the risks of exposure versus not being able to tell customers/distributors "go download X" to fix ten thousand units in the field (knowing that very few of them will), thus requiring you to take them all back and pay the massive overhead associated with an exchange.
Personally, if I were building $2 unit-cost flash drives, I'd make them act like OTP parts after the factory programming. For a $20 unit, I'd leave it in. However, if I were able to keep the costs down to $2 per, I'm probably not paying a lot for firmware engineers and am probably just using 99% of the reference code from the USB chipset/VHDL vendor. :/
posted by introp at 11:51 AM on August 12, 2014
Personally, if I were building $2 unit-cost flash drives, I'd make them act like OTP parts after the factory programming. For a $20 unit, I'd leave it in. However, if I were able to keep the costs down to $2 per, I'm probably not paying a lot for firmware engineers and am probably just using 99% of the reference code from the USB chipset/VHDL vendor. :/
posted by introp at 11:51 AM on August 12, 2014
For the people suggesting that the OS provide a prompt asking what type of device was just plugged in, how you do propose dealing with:
1. Someone plugs in a keyboard/mouse. "Click here to use this USB device as a mouse."
2. The device was a keyboard/mouse that was just plugged in via a laptop docking station.
3. Someone reboots a computer with a malicious USB device that is posing as a keyboard plugged in.
posted by zixyer at 11:58 AM on August 12, 2014 [1 favorite]
1. Someone plugs in a keyboard/mouse. "Click here to use this USB device as a mouse."
2. The device was a keyboard/mouse that was just plugged in via a laptop docking station.
3. Someone reboots a computer with a malicious USB device that is posing as a keyboard plugged in.
posted by zixyer at 11:58 AM on August 12, 2014 [1 favorite]
Today most PCs go immediately from enumeration of the new device to loading the device's drivers and interacting with it. That's the unsafe behavior. The really stupid behavior is autorun, which is one more step beyond that: not just loading drivers and interacting with the device, but mounting it and then beginning to execute whatever arbitrary code it happens to have stored on it. That's facepalm-level stupid, to the point that not even Microsoft seems to think that it's a good move anymore.
Windows has never had autorun for USB mass storage devices turned on by default. It was only ever enabled for CDs.
Of course, that doesn't make much of a difference when your USB device can pretend to be a CD drive with a disc in it.
posted by zixyer at 12:06 PM on August 12, 2014 [2 favorites]
Windows has never had autorun for USB mass storage devices turned on by default. It was only ever enabled for CDs.
Of course, that doesn't make much of a difference when your USB device can pretend to be a CD drive with a disc in it.
posted by zixyer at 12:06 PM on August 12, 2014 [2 favorites]
> Why allow firmware upgrades at all? It's just a USB stick. Who upgrades their firmware on a USB stick?
Slowly I'm starting to grasp, and it does seem to have to do with manufacturing efficiencies, as mirage pane said just a few comments back, for outfits that make USB sticks and also other kinds of USB devices. There's a more detailed paragraph on Bruce Schneier's blog:
An update on a USB flash drive is unlikely. However, I suspect that it's not actually the cause. I mentioned another driver in my post: reuse. Let's say you develop all kinds of peripheral devices. You need a USB controller in most of them. The main difference in them will be the software on the controller and/or its performance. So, you now have two choices: design a bunch of separate USB chips (or ROM's) with separate production; design one programmable USB chip with a production step selecting what firmware to put on it. One makes a hell of a lot of sense to a company focused on the bottom line. Now, repeat this process for many chip designs with maximizing reuse being a key goal and you get the modern IC marketplace.
posted by jfuller at 12:07 PM on August 12, 2014 [1 favorite]
Slowly I'm starting to grasp, and it does seem to have to do with manufacturing efficiencies, as mirage pane said just a few comments back, for outfits that make USB sticks and also other kinds of USB devices. There's a more detailed paragraph on Bruce Schneier's blog:
An update on a USB flash drive is unlikely. However, I suspect that it's not actually the cause. I mentioned another driver in my post: reuse. Let's say you develop all kinds of peripheral devices. You need a USB controller in most of them. The main difference in them will be the software on the controller and/or its performance. So, you now have two choices: design a bunch of separate USB chips (or ROM's) with separate production; design one programmable USB chip with a production step selecting what firmware to put on it. One makes a hell of a lot of sense to a company focused on the bottom line. Now, repeat this process for many chip designs with maximizing reuse being a key goal and you get the modern IC marketplace.
posted by jfuller at 12:07 PM on August 12, 2014 [1 favorite]
So, you now have two choices: design a bunch of separate USB chips (or ROM's) with separate production; design one programmable USB chip with a production step selecting what firmware to put on it.
Sure you can select the programming firmware for a generic chip as a production step, but there are lots of ways to prevent anyone else from modifying that firmware after the product is sold. Has anyone ever upgraded the firmware on their thumb drive?
posted by JackFlash at 12:29 PM on August 12, 2014
Sure you can select the programming firmware for a generic chip as a production step, but there are lots of ways to prevent anyone else from modifying that firmware after the product is sold. Has anyone ever upgraded the firmware on their thumb drive?
posted by JackFlash at 12:29 PM on August 12, 2014
Now I don't feel so thick for not ever taking the time to get USB automounting going on my Fedora machine
dmesg | tail
sudo mount /dev/sdg /mnt/usbd2 -o rw,users
Is a pretty common activity for me
posted by mmrtnt at 12:35 PM on August 12, 2014 [2 favorites]
dmesg | tail
sudo mount /dev/sdg /mnt/usbd2 -o rw,users
Is a pretty common activity for me
posted by mmrtnt at 12:35 PM on August 12, 2014 [2 favorites]
> Does disabling autoplay help at all?
That's an excellent thing to do! But it wouldn't help here.
When you plug a new USB device into your Win PC, Windows hems and haws for a while and then goes "Your new USB device is now installed and ready to use" whether you have autoplay disabled or not. Or maybe "If your new device came with a CD, place it in the CD drawer now". At any rate the OS recognized the new device and has tried to diddle with it in some fashion (and, it seems from these reports, also sometimes allowed compromised device firmware to diddle with the OS) long before it ever gets to looking for any autorun.inf.
posted by jfuller at 12:48 PM on August 12, 2014 [1 favorite]
That's an excellent thing to do! But it wouldn't help here.
When you plug a new USB device into your Win PC, Windows hems and haws for a while and then goes "Your new USB device is now installed and ready to use" whether you have autoplay disabled or not. Or maybe "If your new device came with a CD, place it in the CD drawer now". At any rate the OS recognized the new device and has tried to diddle with it in some fashion (and, it seems from these reports, also sometimes allowed compromised device firmware to diddle with the OS) long before it ever gets to looking for any autorun.inf.
posted by jfuller at 12:48 PM on August 12, 2014 [1 favorite]
Windows will only do autoplay on CD drives (or USB devices spoofing CD drives).
It's kind of a red herring in this discussion, since Windows is never going to open an autorun.inf on a normal USB flash drive (unless you've specifically turned autoplay ON for USB flash drives), and if the USB firmware is compromised, there are many other avenues of infection that don't depend on autoplay.
posted by zixyer at 1:05 PM on August 12, 2014
It's kind of a red herring in this discussion, since Windows is never going to open an autorun.inf on a normal USB flash drive (unless you've specifically turned autoplay ON for USB flash drives), and if the USB firmware is compromised, there are many other avenues of infection that don't depend on autoplay.
posted by zixyer at 1:05 PM on August 12, 2014
dmesg | tail
sudo mount /dev/sdg /mnt/usbd2 -o rw,users
Is a pretty common activity for me
posted by mmrtnt
If it makes you feel happy, your username looks like a UNIX command, and I'm stifling a reflex to go
......
I couldn't resist
Managed memory return (thread-safe)? Multi-mode rotate network? Dammit, why don't I know this?
posted by benito.strauss at 2:27 PM on August 12, 2014 [2 favorites]
sudo mount /dev/sdg /mnt/usbd2 -o rw,users
Is a pretty common activity for me
posted by mmrtnt
If it makes you feel happy, your username looks like a UNIX command, and I'm stifling a reflex to go
man mmrtnt in one of my consoles.......
I couldn't resist
No manual entry for mmrtntManaged memory return (thread-safe)? Multi-mode rotate network? Dammit, why don't I know this?
posted by benito.strauss at 2:27 PM on August 12, 2014 [2 favorites]
For anyone who wants a solid, detailed analysis of the attack surface of a USB port, here's three whitepapers on the subject: Beyond Autorun: Exploiting vulnerabilities with removable storage from 2011, Lessons learned from 50 bugs: Common USB driver vulnerabilities, written in 2013 & A Survey of USB Exploit Mechanisms, profiling Stuxnet and the possible adaptive measures that could have made it more effective from around 2012 or so. The last one goes into greater detail on the range of countermeasures available to defenders.
posted by scalefree at 6:47 PM on August 12, 2014 [4 favorites]
posted by scalefree at 6:47 PM on August 12, 2014 [4 favorites]
devnull: "Here is the fix for this "fundamentally broken" standard:
If a usb keyboard is already connected to the computer, don't let a second one work as a keyboard.
Ta da! Breakage averted."
This works until you reboot with the two plugged in.
posted by pwnguin at 8:56 PM on August 12, 2014
If a usb keyboard is already connected to the computer, don't let a second one work as a keyboard.
Ta da! Breakage averted."
This works until you reboot with the two plugged in.
posted by pwnguin at 8:56 PM on August 12, 2014
So, we use a lot of USB drives in our copy shop at work. Easiest way to exchange data with walk-in customers. All of our workstations are set to scan any removable storage when mounted, and not to auto-run anything.
Given the nature of this new threat, would it give us an added layer of protection if instead of using regular USB drives, what we handed to the customer was one of those USB adapters that accepts an SD card for its memory, and then when we took it back, remove the SD card and pop it into the built-in reader on our PC? So that the USB part of it which touched the customer's PC never touches our computer?
posted by xedrik at 10:21 PM on August 12, 2014
Given the nature of this new threat, would it give us an added layer of protection if instead of using regular USB drives, what we handed to the customer was one of those USB adapters that accepts an SD card for its memory, and then when we took it back, remove the SD card and pop it into the built-in reader on our PC? So that the USB part of it which touched the customer's PC never touches our computer?
posted by xedrik at 10:21 PM on August 12, 2014
It'd still infect the SD card reader you loan to customers though, xedrik. And it's the customers with the valuable data, not the copy shop itself.
Instead, you could preferentially accept files via bluetooth and wifi by warning customers about bad usb devices. I'd imagine a USB adaptor with an Eye-Fi is more secure too.
All very bad news for dead drops based on usb, although wifi ones remain sane.
posted by jeffburdges at 11:04 PM on August 12, 2014
Instead, you could preferentially accept files via bluetooth and wifi by warning customers about bad usb devices. I'd imagine a USB adaptor with an Eye-Fi is more secure too.
All very bad news for dead drops based on usb, although wifi ones remain sane.
posted by jeffburdges at 11:04 PM on August 12, 2014
Given that USB is essentially a network, and each device is a (potentially hostile) network host, which may or may not be what it claims to, perhaps the next step to securing USB is USB firewalls. I.e., place a host on the USB bus, which keeps track of devices connected to the bus and grants/denies access to them and endpoints. The host machine talks to the firewall, presenting prompts from it and instructing it to grant/deny access. I.e.,
“An endpoint of type HID (Keyboard) has appeared on the device FLASH DRIVE. Allow access? [Yes] [No] [No, remove device]"
or even
"The device inserted looks like a disk. Allow access to:
[Storage only] [All USB functions]"
Of course, these could be rephrased to make them more user-friendly. Or even have a non-superuser mode which can be variously locked down (i.e., disks only ever get USB Mass Storage access, each device only has one use allowed, only one keyboard/mouse can be plugged in at any one time; all these can be overridden (i.e., for a peripheral that also poses as a CD-ROM with its own drivers), but only with the superuser password).
posted by acb at 4:21 AM on August 13, 2014 [1 favorite]
“An endpoint of type HID (Keyboard) has appeared on the device FLASH DRIVE. Allow access? [Yes] [No] [No, remove device]"
or even
"The device inserted looks like a disk. Allow access to:
[Storage only] [All USB functions]"
Of course, these could be rephrased to make them more user-friendly. Or even have a non-superuser mode which can be variously locked down (i.e., disks only ever get USB Mass Storage access, each device only has one use allowed, only one keyboard/mouse can be plugged in at any one time; all these can be overridden (i.e., for a peripheral that also poses as a CD-ROM with its own drivers), but only with the superuser password).
posted by acb at 4:21 AM on August 13, 2014 [1 favorite]
benito.strauss ...your username looks like a UNIX command
If you want, I can send you a thumbdrive with the mmrtnt command on it.
posted by mmrtnt at 12:34 PM on August 13, 2014 [2 favorites]
If you want, I can send you a thumbdrive with the mmrtnt command on it.
posted by mmrtnt at 12:34 PM on August 13, 2014 [2 favorites]
> Instead, you could preferentially accept files via bluetooth...
You could also set up a stand-alone machine whose only job would be to burn the contents of guest USB sticks to rewritable CD-ROM
posted by mmrtnt at 12:39 PM on August 13, 2014 [1 favorite]
You could also set up a stand-alone machine whose only job would be to burn the contents of guest USB sticks to rewritable CD-ROM
posted by mmrtnt at 12:39 PM on August 13, 2014 [1 favorite]
« Older A nice story about baseball | Out of thousands of typefaces, all we need are a... Newer »
This thread has been archived and is closed to new comments
Fundamentally broken means the design is flawed. The design of USB is not flawed, it's a dumb serial bus similar to a networking bus at the packet layer. The "broken" part is how people treat them, and what they assume usb devices are capable of. With gadget stacks and small embedded boards, usb devices are capable of far more maliciousness than most people assume and this opens attack vectors via firmware and OS USB stacks.
Furthermore, this is not original research. Specifically, see the Invisible Things lab work on the topic, especially how it relates to plugging drives into virtual machines.
https://twitter.com/cynicalsecurity/status/497681096558260224
https://twitter.com/rootkovska/status/497676536775208960
http://theinvisiblethings.blogspot.ca/2011/06/usb-security-challenges.html
Hell, this story isn't even new to Metafilter, see here.
So yeah, this is your basic, yearly "journalist sees talk at BH/Defcon that everyone already knew, writes breathless story". I guess the "cars have computers inside!!!!!" stories were played out.
posted by yeahwhatever at 11:12 PM on August 11, 2014 [55 favorites]