4 ms·
USB devices that can attack the host computer have been known for some time, and are not the point of the talk. The demonstration methods of attack that use the
by pdkl95 12y ago
USB devices that can attack the host computer have been known for some time, and are not the point of the talk. The demonstration methods of attack that use them are only examples. This threat is about the other direction, where the (compromised) kernel attacks the USB devices firmware.
Nothing the kernel can do defends against the BIOS trusting the mass storage device and booting from it (possibly with an extra HID to press F2 or F12 or whatever to enable the correct boot order), which was covered in the talk.
Also, there's nothing the kernel can do to detect a device that is modifying the data during some of the reads, which was also discussed.
More importantly, it doesn't matter what a handful of technical people do to try and defend their own computers: there is currently a very large set of users that are currently wildly vulnerable running Windows or stock-and-never/rarely-updated Ubuntu. These people like to use their devices in the manner in which they were intended to be used. This has the potential to spread malicious firmware very quickly.
The main vulnerability this talk was trying to demonstrate was not that the USB port on a traditional computer has poor defenses; they are showing that USB devices are easily re-flashable; any USB hardware could become infected, closing the loop.
This possibility of recursive infection over sneakernet suggests that normal, non-technical people need to learn to not trust any kind of shared USB until new devices with unchangeable firmaware can be made.
- cnvogel 12y agoI agree that the current default config in popular operating systems (I.e. what normal non technical people use) is insecure and needs to be fixed. It's just that the defense, in my opinion, is not difficult at all. The main attack vector given by the talk is: device with an additional, unexpected, function. That's the USB stick emulating a keyboard, or the smartphone presenting a network device (which, by the way are functions legitimately found on real hardware). And the only defense against this is a stricter policy on what a computer will talk to, which again technically is binding of drivers. This defense can be implemented rather trivially. The fact that a malicious payload itself reflashes the target is really a very nice hack, and I don't want to belittle this in any way... But in the end, considering the huge amount of updates everybody installs all the time, it's not surprising at all. I have several devices that reflash the connected device to match an updated driver... Of course we are not used to USB sticks doing that, yet. The BIOS is a different problem, and I have no easy solution for that. But in my opinion it's not as important, because in the normal use case (of the non technical user) an OS is running. (And in fact, e.g. on some cromebooks, the keyboard isn't even looked at to boot faster if a special button isn't pressed... So this could be a solution.). A harddisk/stick tinkering with returned data is indeed one of the more interesting things, and has been used to root some devices that first verify a file, then read it again to execute it... But that deserves a completely different defense and itself isn't the topic of this discussion.