8 ms·
Linux kernel: multiple vulnerabilities in the USB subsystem
- gpm 9y agoLooks like there were all found by google doing fuzzing, cool!
- agumonkey 9y agoVery regularly fuzzing uncover a few bugs, impressive.
- deleted 9y ago[deleted]
- mschuster91 9y agoWonder how much of these bugs remain hidden away in the modern kernels. USB and Thunderbolt (which is also carrying PCIe in some modes) and for what it's worth USB-C which can ALSO carry PCIe, in addition to DisplayPort, HDMI and whatnotelse have grown enormously complex. To make matters worse, I guess there are ways for the USB slave device to fingerprint the OS (or: hardware!) running on the host... something like a "pwn me" USB stick working on all three major platforms (OS X, Linux, Windows) or game consoles is certainly possible. And I can perfectly imagine that there are ways to exploit the actual USB controller hardware, which gives unfettered memory access.
- majidazimi 9y agoConsidering scientific statistics, which says there are 0.5 to 25 bugs per KLoC in delivered software, we are really lucky that stuff still work... :D
- red75prime 9y agoCorner cases. Relatively rare until exploited.
- AceJohnny2 9y agoI use the following metaphor: software is like a narrow path high up on the arete of a mountain, with thousand-foot drops on either side. Your goal is to walk down that path. If everything goes well (all the input is as expected), you'll walk the path straight and reach your goal. Bad software (most of it, honestly) has no guardrails: do something wrong, take one step to the side, and you fall crashing off the narrow path. Robust software has guardrails, handles all the error conditions, to make sure you stay on the path (or at least return to the start). Most software is tested against expected input. It's already a lot of work to get things working for the expected case, it's usually enough to stop there. Make the path, expect smart hikers, omit guardrails. This is why stuff still works: most of the time, things go as expected. It is a huge investment to test against all error conditions. I only know of the Space Shuttle that had the robustness requirements to shoulder the cost of implementing that. As I recall, their conventional productivity metrics were abysmal (<1 LoC/day/engineer?), but it was robust. I've worked on High-Availability equipment. The software quality wasn't better than elsewhere, but the recovery mechanisms were much better. For example, all mission-critical data was mirrored to redundant HW/SW, and there was a standby system ready to pick up whenever the active copy crashed... which wasn't too often, but it happened. This is similar to Netflix' "Chaos Monkey" approach to software design.
- kurtisc 9y agoAssuming 0.5 rounds down, that seems like an essentially useless statistic. If you deliver a randomised binary that just doesn't run, does that count as more than one bug?
- colejohnson66 9y ago0.5 rounds up though...
- api 9y agoI swear over-engineering is the cancer of all modern software and systems. It's become my #1 complaint about almost all modern software and systems.
- jacquesm 9y agoWelcome to the club. The problem is that nobody really cares, which makes it super hard to do something about it. In fact, there are plenty of people riding the over-engineering gravy train, which means there are substantial forces to keep things as they are or make them even worse. I don't remember the last job where I was hired where my major contribution was to add something, usually I'm just removing cruft and simplifying things and that's what makes things work again.
- funkymike 9y agoA good day is when I delete more code than I add.
- colejohnson66 9y agoBut then your LoC is negative, and you’re not being productive! /s
- garblegarble 9y agoThat's why I don't delete code, I just comment it out with line comments, and add a note before each line describing why it was removed. I'm so productive! /s :)
- deckard1 9y agoyou joke, but I get the sneaking suspicion that many of my co-workers don't squash commits simply because they are gaming github metrics. Didn't help that my company went as far as saying they used # commits as a guide for annual reviews.
- orclev 9y ago
- derefr 9y ago> USB and Thunderbolt (which is also carrying PCIe in some modes) and for what it's worth USB-C which can ALSO carry PCIe, in addition to DisplayPort, HDMI and whatnotelse have grown enormously complex. Well, sure, the hardware standards required to achieve this are complex. But looked at from another angle, the software required to handle this is simpler than before. Before, a kernel had to have, effectively, fifteen drivers for the various IO controller-hub chips in the system, and then fifteen matching subsystems to manage their respective protocol stacks (i.e. physical, link, and [for several of the standards] network layers in the OSI model.) With consolidation, now you have maybe half as many drivers for controller-hubs (because both USB-C and Thunderbolt are managed by the same hub, etc.) and far fewer stacks, because there's only one stack per common protocol standard. Every port being "unified into" a {USB, PCIe, DisplayPort, HDMI, ...} port means that now, that set of protocols—taken together—are now where a lot of the eyes in kernel development end up. So each of these protocol stacks is being picked over far more thoroughly than before. It's the same thing that happened when USB obsoleted all the previously-proprietary standards for OSI layers 1 and 2 over serial or parallel ports: suddenly, instead of 1500 individual implementations of those layers [either as proprietary drivers from the manufacturer, or as reverse-engineered parts of Linux] you had one, much-more-well-done OSI layer-1/2 driver for USB. There were still 1500 drivers, for whatever those devices did on top of OSI1+2 (though that number gradually decreased as common HAL driver standards for things like HID peripherals emerged), but those drivers now each had much less code and therefore much less attack surface. (And, as well, a lot of those drivers no longer "did" anything much at the hardware level, instead just packing and unpacking packets from the bus into data for a system service to hold onto, and therefore these drivers could now be more heavily sandboxed by the OS. This is ~half of why Windows XP crashed less than Windows 9x: a USB device-driver crash was, almost always, a non-fatal event.)
- kevhito 9y agoI'm really not sure this is right, it just doesn't ring true to me. Yes, in the bad old days, we had dozens or hundreds of different drivers for specific network cards, serial cards, parallel port chips, audio cards, floppy controllers, disk drivers, etc., plus the tangled mess of scsi and ata/sata/pata storage stacks, tcp/ip/tokenring/ethernet/netbios/smb/appletalk network stacks, tty/vtty/serial terminals, and so on. Bugs in the higher-level stacks, like sata, would be impact very broadly. But a bug in one specific network card driver would, generally, only affect the subset of people who actually had that specific network card. And many of those old drivers were not really all that complicated, because they were specific and narrowly tailored. Buggy as anything too, of course, and didn't get much scrutiny due to the huge variation in software. Now everything is subsumed under a massive IO controller-hub chip driver. At least the last time I checked, all those tangled upper-level stacks are still there, but they are just entwined with a hugely complex mess of usb/thunderbolt/usb-c mess. So you'd still have all the complexity of a sata stack, but that's nested on top of a scsi stack, sitting on a PCI stack, all nested inside a USB-C stack.
- walrus01 9y agoThunderbolt is used as an attack vector by some NSA APT/rootkit: https://www.wired.com/2017/03/wikileaks-shows-cia-can-hack-macs-hidden-code/ https://www.wired.com/2017/03/wikileaks-shows-cia-can-hack-m... https://securinghardware.com/articles/SLOTSCREAMER/ https://securinghardware.com/articles/SLOTSCREAMER/ also duplicated by others, back in 2015: https://www.extremetech.com/mobile/197005-new-apple-malware-is-undetectable-unstoppable-and-can-infect-any-thunderbolt-equipped-device https://www.extremetech.com/mobile/197005-new-apple-malware-...
- mshook 9y agoFingerprinting has been done: https://cise.ufl.edu/~butler/pubs/sadfe11.pdf https://cise.ufl.edu/~butler/pubs/sadfe11.pdf And given you can easily reprogram thumb drives and such, it's easy to do evil stuff with them. You can plug a thumb drive with a reprogrammed firmware which will detect the OS based on IO patterns and then it can tell the OS it's also a keyboard and runs command for you. https://srlabs.de/bites/usb-peripherals-turn/ https://srlabs.de/bites/usb-peripherals-turn/ https://srlabs.de/wp-content/uploads/2014/11/SRLabs-BadUSB-Pacsec-v2.pdf https://srlabs.de/wp-content/uploads/2014/11/SRLabs-BadUSB-P... https://github.com/brandonlw/Psychson https://github.com/brandonlw/Psychson https://www.computerworld.com/article/2690790/tools-for-creating-malicious-usb-thumb-drives-released.html https://www.computerworld.com/article/2690790/tools-for-crea... From the article: "During their Derbycon demonstration, which is available on YouTube, the two researchers replicated the emulated keyboard attack, but also showed how to create a hidden partition on thumb drives to defeat forensic tools and how to bypass the password for protected partitions on some USB drives that provide such a feature."
- mschuster91 9y agoWow, the situation is even worse than I imagined - I thought fingerprinting was theoretical, not that there are actual practical examples in the wild. Jeez.
- fauigerzigerk 9y agoApparently, these are all denial of service attacks using a specially crafted USB device that you have to physically insert into the Linux machine. Pulling the plug sounds easier :)
- digi_owl 9y agohttps://wicg.github.io/webusb/ https://wicg.github.io/webusb/
- fauigerzigerk 9y agoCare to elaborate?
- geofft 9y agoI don't think that's relevant - WebUSB exposes physical USB devices on the local machine to code running inside the browser. It does not allow code running inside the browser to access the host USB stack as if it were a physical device (in order to emulate a USB device, forward one across the web, etc.).
- staticassertion 9y agoIt's unclear whether or not these are all strictly DOS. Some seem like they may be exploitable.
- greenhouse_gas 9y agoI thought that it would help even if the USB stack _would_ be secure, as any USB device has direct access to the motherboard/PCI?
- cjbprime 9y agoIt sounds like you're thinking that any device connected to the motherboard or PCI bus has access to read/write arbitrary memory on the host through Direct Memory Access or some other mechanism. This isn't true for a couple reasons: * The PCI bus access is given to the _USB hub_, since that's what's connected to PCI, not to the USB device you plugged in. The USB hub can talk to the USB device using whatever restrictive protocol it wants to. The USB protocol doesn't give DMA access to devices -- it polls registers on the devices for commands and data. * Even if it were a hostile device connected to the PCI bus, modern machines, both desktop-class (e.g. x64) and mobile (e.g. modern ARM cores in cellphones) use IOMMUs to give a virtual view of just the device's own addressable memory to the device, not the full system memory map. (I might be mistaken about some of this, but that's my understanding.)
- ihaveahadron 9y agoin plain english: i don't care about your python hacks. im better than you. i look at the place, often, the least people are looking. its a strategy choice. if something showed python hacks to be "more profitable" than "low level hardware hacks", that's probably what id be reading let me know when you want to deviate from logic..
- rini17 9y agoAFAIK grsecurity allows to disable USB completely after boot, which should avoid many of these problems. Is there another similar solution?
- jlgaddis 9y agoBlacklist the various USB modules? Or disable USB in BIOS?
- etqwzutewzu 9y agoTLDR: severity is denial of service (as of today) for all of them
- staticassertion 9y agoBut if you actually read the descriptions there are plenty that look like they'd have great potential for code execution.
- easytiger 9y agoThese are all DOS attacks ( that require a crafted USB device and physical access. At which point i guess you could just powerdown. Only if chained with another vuln, (e.g. access to iLO) could you actually do anything.
- inetknght 9y ago> or possibly have unspecified other impact > use-after-free and system crash > general protection fault and system crash > out-of-bounds read and system crash > NULL pointer dereference and system crash I don't know about you, but I think a smart person could figure out how to abuse these to get data out of my machine.
- ky738 9y agoThis is one of the many reasons why the kernel should have been written in Rust.
- jlgaddis 9y agoLinux, which first appeared in 1991, should have been written in a language that didn't exist until 19 years later? When will your rewritten-in-Rust version of the kernel be released?
- kardos 9y agoA wholesale rewrite is fantasy, but piecewise replacement might be plausible. Is it technically possible to write a driver in Rust and add it to the kernel in a reasonable way? That is, without gobs of fragile shims, etc.
- kogepathic 9y ago> Is it technically possible to write a driver in Rust and add it to the kernel in a reasonable way? That is, without gobs of fragile shims, etc. I think this is highly unlikely. The Linux kernel lacks an internal ABI [0] which would make writing drivers in a different language and targeting them at multiple kernel releases essentially impossible. Many, many people and organizations writing drivers have complained over the years about the lack of an internal ABI. [1] [2] I would go so far as to say it's why Linux on ARM is such a dumpster fire. SoC vendors provide an SDK based on a certain kernel, and OEMs forever ship this kernel (with occasional backports for really severe bugs) because porting the device-specific changes to a newer kernel is just too much effort. [0] https://en.wikipedia.org/wiki/Linux_kernel_interfaces https://en.wikipedia.org/wiki/Linux_kernel_interfaces [1] https://stackoverflow.com/questions/827862/why-i-need-to-re-compile-vmware-kernel-module-after-a-linux-kernel-upgrade https://stackoverflow.com/questions/827862/why-i-need-to-re-... [2] https://news.ycombinator.com/item?id=9220973 https://news.ycombinator.com/item?id=9220973
- pjmlp 9y ago
- tomc1985 9y agoThese fixes will be backported to longterm kernel versions right?
- bweston92 9y agoYou can do anything with physical access anyway.
- staticassertion 9y agoThis is making a ton of assumptions about your target. Is it a desktop user? Then possibly. Is it a server? What type? Does it have a keyboard/ monitor? Maybe a USB is how you access this device - so a USB that can get control over the kernel is suddenly your most viable attack method.
- bluGill 9y agoTrue, but with these bugs it doesn't have to be the attacker that personally has physical access to the target machine. For secure sites the attacker may not be able to get past security, but if the device is innocent enough it might. If you are a secure site you need to oversee the manufacture of all your USB cables, otherwise you don't know that someone hasn't put an attack into the cables you ordered.
- kurtisc 9y agoAre there any situations where this would be a vulnerability but using a USB device as a HID would not?
- sengork 9y agoFireWire used to be a similar basket case. Don't think the firmware/drivers got fixed, instead it became an obsolete hardware port and replaced by TB/USB/etc...
- jimrandomh 9y agoNote that "crafted USB device" is a bigger attack vector than it sounds like; if paired with vulnerabilities in USB devices themselves, you can have hosts that infect USB devices and USB devices to make them infect other hosts.