Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Linux Technology

Linux Has a USB Driver Security Problem (bleepingcomputer.com) 156

Catalin Cimpanu, reporting for BleepingComputer: USB drivers included in the Linux kernel are rife with security flaws that in some cases can be exploited to run untrusted code and take over users' computers. The vast majority of these vulnerabilities came to light on Monday, when Google security expert Andrey Konovalov informed the Linux community of 14 vulnerabilities he found in the Linux kernel USB subsystem. "All of them can be triggered with a crafted malicious USB device in case an attacker has physical access to the machine," Konovalov said. The 14 flaws are actually part of a larger list of 79 flaws Konovalov found in Linux kernel USB drivers during the past months. Not all of these 79 vulnerabilities have been reported, let alone patched. Most are simple DoS (Denial of Service) bugs that freeze or restart the OS, but some allow attackers to elevate privileges and execute malicious code.
This discussion has been archived. No new comments can be posted.

Linux Has a USB Driver Security Problem

Comments Filter:
  • by Anonymous Coward on Wednesday November 08, 2017 @04:08PM (#55515309)
    you're already pwned
    • by Calydor ( 739835 ) on Wednesday November 08, 2017 @04:22PM (#55515377)

      If all it takes is access to plug in a USB dongle, that's a different kind of access than being able to open up the machine and tinker with it. Secretary turns her back for a moment? Plug it in while you can.

      Hell, with the tendency for people to plug in USB keys found on the street still to this day, that's all that would be required to exploit these flaws in an otherwise impenetrable building.

      • by account_deleted ( 4530225 ) on Wednesday November 08, 2017 @04:25PM (#55515393)
        Comment removed based on user account deletion
        • by Jeremi ( 14640 ) on Wednesday November 08, 2017 @04:38PM (#55515471) Homepage

          Wow, Hollywood has actually been accurately portraying the state of security in Linux for years, and nobody realized!

          If it turns out that the secretaries of the world have been running Linux all these years, I will be rather surprised :)

        • by cstacy ( 534252 ) on Wednesday November 08, 2017 @05:26PM (#55515705)

          Secretary turns her back for a moment? Plug it in while you can.

          Wow, Hollywood has actually been accurately portraying the state of security in Linux for years, and nobody realized!

          No, they haven't been portraying it accurately for years. But in the last few weeks we have seen actresses and secretaries in Hollywood coming forward with the story of what happens when they turn their backs and executive producers try to "plug it in while they can".

          • Re: (Score:2, Funny)

            by epyT-R ( 613989 )

            Of course, all it takes is a few plug-in attempts to create kernel panics...or is that moral panics?

            • by tlhIngan ( 30335 ) <slashdot.worf@net> on Wednesday November 08, 2017 @07:27PM (#55516355)

              Of course, all it takes is a few plug-in attempts to create kernel panics...or is that moral panics?

              I've had it happen to me while I was developing a USB device. Plugged it into a Linux machine and it kernel panics immeidately. No, plug it into Windows and nothing happens.

              It turned out I screwed up the USB descriptors I was returning - Linux didn't like that I set the descriptor type wrong.

              Granted, this is something I did many many many years ago (around the time of the great east cost blackout) so I expect that it would be somewhat more robust now.

              It's also interesting to see how different OSes reacted - the USB descriptor is a fixed size, but some OSes (Windows, notably) only do a partial request - I think it was 5 bytes - in order to get the USB descriptor type and length bytes, then it re-ran the request with the proper size. Linux at the time simply did a proper sized request - the descriptor size is fixed and unchanging so what Windows did was completely unnecessary unless it was to ensure that devices responded properly.

      • by Anonymous Coward

        Secretary accepts flash drive from student to print homework assignment on the office printer...

        • Re: (Score:3, Funny)

          by Anonymous Coward
          UNREALISTIC. Windows does not have these same vulns. Secretary is safe.
          • UNREALISTIC. Windows does not have these same vulns.

            So, like the fellow that found the Linux vulnerabilities, obviously you've examined the Windows source code to ensure that Windows didn't have them, thus allowing you to make a definitive statement such as the one above.

            Oh, wait ....

            • by Anonymous Coward

              Well I know Plan9 is cannot be similarly affected, as it runs all USB drivers in userspace as separate processes. I know many Windows USB drivers run in userspace but I can't be certain all do. In any case it would be a good idea for Linux to scrap the shitty design that is kernel mode USB drivers and run the USB stack as a usermode helper with privsep+privdrop. Doing anything else is negligent engineering.

          • Wrong, secretary is not safe because regardless of operating system, the 400 joule jolt stored in capacitors in the thumb drive just fried said secretary's computer!
          • yeah windows doesn't have a feature called autoplay

          • Are you sure. These vulnerabilities were all found with the same kernel fuzzing tool that, as far as I know, has not been ported to work on other operating systems. It would be great for someone to run the same thing on *BSD and Windows - similar exploits are almost certainly in all systems, the difference is that the Linux ones are now known and fixed.
      • by Anonymous Coward

        It's important to understand that USB does not include any type of security or authentication. Secondly, it requires a custom USB device. Even many experienced developers are not in a position to craft such things. You're basically talking about embedded developers.

        Such exploits are going to be fairly specialized AND you still require either physical access or social engineering to achieve the goal. Though a common form of social engineering is to drop USB drives in parking lots you would to exploit. This i

        • Secondly, it requires a custom USB device. Even many experienced developers are not in a position to craft such things. You're basically talking about embedded developers.

          So what? All it takes is one or two embedded developers to craft such things with a barely usable management UI, flood Baidu or eBay with their wares, and then every man and his dog has access to one.

      • by Anonymous Coward

        Secretary turns her back for a moment? Plug it in while you can.

        Hello sexual harassment lawsuit.

      • It's kinda sad that it's not common knowledge by now, but USB itself has physical hardware vulnerabilities that are not fixable at the driver level. Fixing the security flaws in the USB drivers is kinda like fixing the security flaws in a lock on a paper window.

        • Please tell me more. I recall a rather problematic security issue with early FireWire implementations that allowed direct access to a computer system's memory. Wasn't this used to break some DVD encryption keys? ThunderBolt might have similar problems but I have not looked into it thoroughly, this is likely much harder to fix since ThunderBolt is an extension of the PCI bus. ThunderBolt 3 uses USB-C for it's standard connection port, is this what you mean by a physical hardware vulnerability? This kind

          • by AC-x ( 735297 )

            What USB hardware vulnerabilities do you know about?

            One exploit I remember from a few years back is a custom USB device emulating a keyboard and mouse can issue commands via keyboard shortcuts and mouse clicks [github.com].

            Another one is emulating a network adapter to intercept and alter network traffic [boingboing.net].

            • Emulating a keyboard and mouse is not any more a "hardware vulnerability" than having access to PS/2 or any other input port that one might have access to. These kind of attacks have existing long before USB.

              Emulating a network adapter is not much of a vulnerability either since one could also attack by Ethernet or wireless connection. This is also fairly simple to protect against by disabling the use of USB network adapters and/or setting routing priority on the computer.

              I thought that there was somethin

              • by AC-x ( 735297 )

                I think you're falling in to the same trap as some other posters with "physical access = already pwned".

                USB is somewhat more dangerous because they are also ubiquitous inconspicuous storage devices and computers often have multiple easy to access USB ports.

                PS/2 ports are used exclusively for keyboard and mice and the ports are generally at the back of the computer, so you're not going to be able to trick someone into inserting a device like you could with something that looks like a USB stick and to do it y

                • The claim was that USB has physical vulnerabilities that are not fixable at the driver level. Problems of people inserting storage or network devices can be fixed by disabling or removing drivers for those devices. If access to front ports are a problem then disable the front ports. Disabling front ports can be done at the driver level, or BIOS level, and not just by filling them with glue.

                  Perhaps there is a problem where people need ready access to USB storage, so front ports cannot be disabled, AND nee

                  • by AC-x ( 735297 )

                    The other claim was that this was not common knowledge, but I'm pretty sure it's common knowledge that USB keyboards exist and drivers for them are standard install on most any operating system.

                    That's not the claim being made.

                    If someone wants to claim that it's not common knowledge that keyboard emulators can fit in a device that can be disguised as a flash drive then that might be something that could stand up.

                    That is the claim, and I would say it's a very safe claim to make.

                    But then someone would have to be engineered to plug in a flash drive and for some reason allow the device to "drive" the computer until the payload was delivered. If the person doing this was aware that the device would do this, such as being a party to the crack attempt, then this is still not something unique to USB. Such a person could easily be engineered to plug a device into a PS/2 port.

                    I disagree; Giving someone files on a USB stick is such a common and natural thing to do that the vast majority of people wouldn't think twice about it. Just leaving one lying around might be enough, and it may be possible to install a hack on a user's own USB stick [wonderhowto.com] if you can get brief access to it.

                    Giving someone a dongle to plug into a port that they may have never used on their computer (and increasingly isn

                    • I disagree; Giving someone files on a USB stick is such a common and natural thing to do that the vast majority of people wouldn't think twice about it. Just leaving one lying around might be enough, and it may be possible to install a hack on a user's own USB stick if you can get brief access to it.

                      My comment was that people would have to plug this in, watch the device take over their screen and do nothing about it. That's going to take some crazy planning to distract the person or something, or as I pointed out the person would have to be in on the attack.

                      Giving someone a dongle to plug into a port that they may have never used on their computer (and increasingly isn't even present) would already be more suspicious, and only give you keyboard access with nothing else.

                      I point out the use of PS/2 and such just to show how old these attacks are. People have been doing this for a long time. The ports people use to plug in their keyboards have changed is all. You want someone to plug in a keylogger on their PC a

                    • by AC-x ( 735297 )

                      You're ignoring all the additional scenarios this opens up that wouldn't be possible otherwise -

                      Any company that deals with large digital documents where it's normal to receive files on usb sticks / drives.

                      Plugging a miniature USB stick into an unattended computer quickly and walking off.

                      Giving branded USB sticks away.

                      Leaving USB sticks lying around.

                      Your examples mostly revolve around already having social engineered a position of trust (if you're already doing maintenance on a user's machine what do you ne

                    • You're ignoring all the additional scenarios this opens up that wouldn't be possible otherwise -

                      USB adds nothing that an an otherwise equivalently capable device could not do with another appropriate port.

                      Any company that deals with large digital documents where it's normal to receive files on usb sticks / drives.

                      The places I've been it's rare to send data on a flash drive as it does not prevent modification in transit. We use optical discs, CD-R, DVD-R, or BD-R, depending on the size. If the stack of polycarbon discs starts to look a bit think then its sent on a SAS drive in a pelican case. Each end will have the appropriate drive array for the caddy the drive is in. Many files are simply sent over the

                    • by AC-x ( 735297 )

                      USB adds nothing that an an otherwise equivalently capable device could not do with another appropriate port.

                      No other port has nearly the range of possible attacks or the ubiquity of use as USB.

                      The places I've been it's rare to send data on a flash drive as it does not prevent modification in transit. We use optical discs, CD-R, DVD-R, or BD-R, depending on the size. If the stack of polycarbon discs starts to look a bit think then its sent on a SAS drive in a pelican case. Each end will have the appropriate drive array for the caddy the drive is in. Many files are simply sent over the network through a number of data storage services, if the file cannot simply be e-mailed.

                      In niche / high security organizations sure, but most companies would be fine to receive files that way.

                      That's frowned upon. Depending on the time and place this is a breach of protocol, merely inconsiderate, and may involve a verbal reprimand. Such drives are to be handed to the person, placed in their mail box, or left with a neighboring coworker.

                      We're talking about hacking here, not colleagues playing pranks on each other. A disgruntled employee or even guest of the building could slip a small USB stick into a computer much more discreetly than even hooking a (much more limited capability) PS2 keylogger onto a system and easily go unnoticed.

                      There's enough distrust that I'm not sure this would go over well. They'd be examined or must come from a trusted party

                      Yeah you can tell empl

                    • No other port has nearly the range of possible attacks or the ubiquity of use as USB.

                      That's just like saying every house has a front door therefore they are vulnerable. There's nothing inherently insecure about USB that previously common ports did not have.

                      USB combining keyboard/mouse with storage and network adds nothing or very little. The ubiquity of floppy and optical drives meant any storage based attack is no different than a flash drive attack, except maybe the speed and size but then computers have always getting smaller and faster. A keyboard emulator attack requires someone to

                    • You're still completely missing the point of this -

                      A malicious USB device can bypass restrictions on autorun by using keyboard shortcuts to execute commands (eg. via win-r) that a storage-only attack can't.

                      A malicious USB device can execute an attack too quick to stop, and possibly before the user has even looked up at the screen again.

                      Computers can't realistically have their usb keyboard and mouse drivers disabled.

                      It's not making a mountain out of a mole hill, it's noting an interesting attack vector that

                    • It's not making a mountain out of a mole hill, it's noting an interesting attack vector that the ubiquity and multi-function nature of USB makes possible.

                      You are about 15 years too late. This is not interesting now. USB came out over 20 years ago, and has been quite common since the early days of Windows XP and Mac OS X 15 years ago. If this was any real effective attack vector then maybe someone would have done more than just some interesting demonstrations with a $30 embedded computer. Sure, lots of things are possible if someone throws enough time and effort behind it. If this has somehow escaped into the wild then maybe it can be "interesting".

                      Very

                    • by AC-x ( 735297 )

                      Well that's a really silly thing to say isn't? That there hasn't been any known attacks but now cheap powerful usb dev boards are available and people are releasing proof of concept code, there still won't be any attacks? Dear me, next you'll be saying KRACK attack is nothing because it's been sitting in plain sight in the wpa2 spec for 10 years!

                    • I didn't say there won't be any attacks, I said that there are no reports of this style of attack being successful against anyone, therefore this threat is merely theoretical. If this moves out of theory into practice then we might have something "interesting". Since this has remained theoretical for 20 years then my expectations of such a thing happening anytime soon are quite low.

                      Maybe someone could find these hacks useful for something that doesn't involve breaking into another computer. I have some i

                    • by AC-x ( 735297 )

                      I mean, it is more than theoretical now though as there is readily available hardware and several working proof of concepts. Certainly one to keep an eye on.

      • Yes and no. Denial of service is easy for some of the drivers, on more than just Linux. Just say your device descriptor has the maximum number of interfaces, each interface has the maximum number of endpoints, and things like that. But then again, you can just have a USB device that fries your computer completely since it's really a big supercap.

        Now taking over a computer this way is harder. Certainly there could be exploits, but I don't necessarily think this is just Linux either.

    • by AHuxley ( 892839 )
      AC a file on a USB device on a computer should not be able to take over a computer or wider network.
      Thats how the penetration testers often work. They charm or sneak into a building past security and put a usb device into any computer they need to get access to.
      They are from "tech support", know the boss and want to show a "charity" movie the boss is interested in to the staff ...
      Someone grants access to their computer and usb to "help" the expert.. or the now trusted person the boss knows...
    • by AmiMoJo ( 196126 )

      you're already pwned

      Not really, especially today when great steps have been made towards creating physical security for computers.

      We have self-encrypting SSDs, and AMD's latest parts support encrypted RAM. The keys are stored in secure enclaves of the CPU, so things like cold boot attacks and removing RAM doesn't work any more.

      Combine that with a secure OS and secure boot via UEFI and the machine is pretty difficult to p0wn even with physical access. You would need to get to the level of replacing firmware in some critical per

  • by Archangel Michael ( 180766 ) on Wednesday November 08, 2017 @04:08PM (#55515311) Journal

    I think i found the problem. Kernel Space drivers are always prone to these kinds of problems. This is not new.

    The depth of the problem is newish, but only because someone peeked in and saw flaws.

    • by Anonymous Coward

      That's why we have https://www.kernel.org/doc/Documentation/usb/authorization.txt

      now, that it is not used it is a whole different matter

    • I'm assuming these things happen because the USB device drivers load microcode from the USB device? If so why can't these things be sandboxed-- no reason to give them file access or network access or even much memory. If it's a matter of top line speed then let the user decide-- sandbox by default and let the user have a switched labeled "open your mouth and close your eyes-- give me a tiny bit more speede in return for butt neckid security."

      • I'm assuming these things happen because the USB device drivers load microcode from the USB device?

        No.

        The tool referred to does "fuzzing". That means it talks the protocol, but tries a variety of minor corruptions to the packets it sends, to see if any of them exercise a bug in the drivers on the other end of the wire.

        So any bugs found are in the driver and related to defective error-checking on incoming messages, not to hypothetical code loaded from the USB peripheral.

        (Granted, if some driver DID do somet

      • No microcode. However there's an enumeration process that involves reading data from the device. Ie, you can try to override some internal buffers of the buggy driver by claiming to have longer descriptors than it has room for.

      • by AmiMoJo ( 196126 )

        I don't know of any USB device drivers that loads microcode from a USB device. There are plenty that do it the other way around - the USB is just a bootloader + RAM, with the application code stored in the driver and loaded every time it is plugged in.

        The issue is that the USB device sends device descriptors to the computer that describe what it is and how to talk to it. By looking at that data the OS can device which driver to assign to it. By sending malformed descriptors you can trigger bugs in the Linux

  • by Anonymous Coward

    Linux drivers can mitigate that but they will never stop the problems in the USB spec.

    • So when you plug in a flash drive, you are giving control of your entire computer to it. Every time. Like when your kids give you a USB with something to print from their virus riddled school.

      At least Windows is no longer supposed to automatically execute code it finds on the drive (or CD, if that is what the USB is emulating). But it is *long* over due that I should be able to plug in a USB drive and still be safe. May need special ports. Or a rule that Keyboards are only detected on startup. Etc.

  • by DarkOx ( 621550 ) on Wednesday November 08, 2017 @04:36PM (#55515463) Journal

    Severs in locked data centers - safe
    PCs in locked offices / homes - safe
    Laptops - safe if you shut it down and have bios password to enable boot, probably safe with encrypted root fs, provided machine is shutdown to begin with.
    Laptop in yours own hands - safe

    Now all those consumer devices that the manufacture won't let you have access to, ROOTED!

    This is a win.

    • And don't plugin that usb key you found in the parking lot... Though usually I would trust a linux machine for examining an unknown usb device. Certainly more than I would trust a Windows box. So this is a little troubling.
      • by Wolfrider ( 856 )

        --Anymore, one of the only devices you can "trust" plugging a random USB device into would be a Raspberry Pi. Cheap and disposable if necessary; you can run ClamAV tests from there, and see if it lets out the magic smoke.

  • So, i guess it affects android too..

    Oh, i see your phone is low on battery, here - have a charger

    • by dargaud ( 518470 )
      Which is probably why the latest Androids are in charge-only mode when you plug them in. You have to select a menu to activate data exchange (MTP) or other USB modes.
  • Authors of Qubes OS have long stated that monolithic kernel crappiness means that Linux, Windows kernels cannot be used effectively for security. The solution is to isolate the risk (large attack surface) they pose using relatively secure type-1 hypervisors. USB and NIC/wifi/bluetooth controllers are compartmentalized in their own virtual machines.

  • by blindseer ( 891256 ) <blindseer@@@earthlink...net> on Wednesday November 08, 2017 @10:18PM (#55517157)

    I've worked in secure environments and as someone that has obtained security certifications I see all kinds of problems with USB beyond improperly coded drivers. One common practice not that long ago was to disable any USB ports to stop people from plugging in things they weren't supposed to. This was only possible while PS/2 ports for keyboards and mice were still commonplace. (There was also that short period where some Apple computers had both ADB and USB ports.)

    I like USB-C. It's quite the improvement over what we've had before. I am a bit concerned on how this affects the security of our devices in the future. Controlling things like someone offering a "charger" for a laptop or cell phone to try to sneak into a device can be managed in many ways. Dedicated ports for video, keyboard, mouse, and even Ethernet had inherent security in that they did only so much which prevented certain security issues. Will all these ports go away and be replaced with USB-C?

    Again, I really like USB-C as it adds convenience and capability that nothing else offered before. It also adds security issues that a simple list of "dos and don'ts" cannot cover for many less technically knowledgeable people to follow. Securing computers from many kinds of attacks is going to be an increasingly difficult problem unless we get off this mentality of one port to rule them all.

    Maybe we'll see some means to better secure USB. Maybe we'll see computer systems that will allow one to disable anything that is not a HID or power device from being recognized on USB in the firmware. Maybe OS developers will provide better granularity on what USB ports are allowed to do.

    Maybe we'll get PS/2 ports back again. Probably not. I do think something has to give. If we can't have the inherent security of feature limited ports then we will need some security through better management of the ports that replace them.

    • by AmiMoJo ( 196126 )

      PS/2 and USB HID devices are just as much of a security risk, possibly more so. Simply emulate a keyboard and you can type arbitrary commands into the machine. You might even be able to wake it up from sleep mode in the middle of the night.

      • PS/2 is a security risk? Really - I thought it was pretty safe. Sure, you can plug in a keyboard emulator, but you've still got to get past the login screen to do anything. For you to be able to read back the result of your password cracking, you'd have to decode the VGA signal.

        Given the choice between a USB port or a PS/2 + VGA on the back of a server, PS/2 is the more secure choice. What makes most sense on your laptop is up for a bit more debate, but seeing as that has a screen and keyboard already, I'd

  • With a dongle : http://hexus.net/tech/news/per... [hexus.net]
    With some Linux 'firewalls' : USBGuard, https://github.com/dkopecek/us... [github.com] , USBauth, https://github.com/kochstefan/... [github.com]
    Nice paper on LWV, that's still paying this week but will become free after 8 days as usual : https://lwn.net/Articles/73830... [lwn.net]
    HTH,
    Hervé

    BTW : anyone in region 06 in France wishing to share shipping costs for the dongle?

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Working...