2 ms·

> The sensible alternative is to not enable this functionality at all. Far too many people seem to think the solution to security problems to ignore security a

by pdkl95 11y ago

> The sensible alternative is to not enable this functionality at all. Far too many people seem to think the solution to security problems to ignore security and only consider the features you want. This is such a bad idea that I'm starting to question the motives behind it. If I wanted to break the security of an important class of software, it would look something like this "standard". > USB security is a joke Most hardware security - USB or otherwise - doesn't exist. Local peripherals were never designed with security in mind.

icebraining 11y ago
Local peripherals won't be exposed unless they specific declare they support WebUSB.
- pdkl95 11y ago
  Do you really think attackers will respect that limitation after they overflow a buffer in the browser? You're only looking at how it's supposed to work. What matters is how it will be exploited.
  - icebraining 11y ago
    With or without WebUSB, browsers can already talk to USB devices, and so if you can exploit the browser to run your own code, you can too.
    - pdkl95 11y ago
      Then show me the USB interface code in firefox. As far as I know, it doesn't exist.
      - icebraining 11y ago
        It's in the Win32 DLLs that Firefox links against.
- ZenoArrow 11y ago
  To see all potential security issues, you need to look at the whole tech stack. A single USB device can have multiple drivers, and although only one is active at any given time the decision over which one to use can be influenced by applications. https://msdn.microsoft.com/en-gb/library/windows/hardware/hh920375(v=vs.85).aspx https://msdn.microsoft.com/en-gb/library/windows/hardware/hh... "A USB configuration defines the capabilities and features of a device, mainly its power capabilities and interfaces. The device can have multiple configurations, but only one is active at a time. The active configuration isn't chosen by the USB driver stack, but might be initiated by an application, a driver, the device driver. The device driver selects an active configuration. A configuration can have one or more USB interfaces that define the functionality of the device. Typically, there is a one-to-one correlation between a function and an interface. However, certain devices expose multiple interfaces related to one function." So let's say I want to exploit this new WebUSB API. If I infect your computer with malware that installs a second USB driver for the hardware I want access to, and this second driver has support for WebUSB, I could theoretically control the driver being used by making a WebUSB request for the device, thereby exposing the hardware for further exploits.
  - icebraining 11y ago
    This is what Raymond Chen calls "being on the other side of the airtight hatchway". If you can install an USB driver on my machine, it's because you can run native code on my machine, and so you can use that to talk to the USB device without requiring WebUSB.
    - ZenoArrow 11y ago
      The difference between using the malware itself to communicate via the web and using WebUSB to do so would be in malware detection. If an unidentified EXE hidden in your Windows partition is communicating via the web that's going to look a lot more suspect than a driver which is trusted by the system. The malware that installed the driver could remove itself after installing the driver, taking out another way to track it down.
      - 11y ago
- makomk 11y ago
  In order for this to be even vaguely secure, every single device that declares support for WebUSB has to refrain from allowing firmware updates over WebUSB despite how incredibly convenient this is, and despite how much of a support nightmare it would be to roll out bugfixes to users without it, and despite them being developed by hardware manufacturers who generally don't give a fuck about security. I can't see this happening. (Allowing remote firmware updates effectively gives full remote code execution on the host PC to the website behind the device, since it can then emulate USB input devices.)
  - icebraining 11y ago
    Oh, I don't disagree; I would bet some of those devices will get owned. My only hope is that the manufacturers will set the "origin allowed" field that says what domains may access the devices.

by pdkl95 11y ago

icebraining 11y ago

Local peripherals won't be exposed unless they specific declare they support WebUSB.

pdkl95 11y ago
Do you really think attackers will respect that limitation after they overflow a buffer in the browser? You're only looking at how it's supposed to work. What matters is how it will be exploited.
- icebraining 11y ago
  With or without WebUSB, browsers can already talk to USB devices, and so if you can exploit the browser to run your own code, you can too.
  - pdkl95 11y ago
    Then show me the USB interface code in firefox. As far as I know, it doesn't exist.
    - icebraining 11y ago
      It's in the Win32 DLLs that Firefox links against.
ZenoArrow 11y ago
To see all potential security issues, you need to look at the whole tech stack. A single USB device can have multiple drivers, and although only one is active at any given time the decision over which one to use can be influenced by applications. https://msdn.microsoft.com/en-gb/library/windows/hardware/hh920375(v=vs.85).aspx https://msdn.microsoft.com/en-gb/library/windows/hardware/hh... "A USB configuration defines the capabilities and features of a device, mainly its power capabilities and interfaces. The device can have multiple configurations, but only one is active at a time. The active configuration isn't chosen by the USB driver stack, but might be initiated by an application, a driver, the device driver. The device driver selects an active configuration. A configuration can have one or more USB interfaces that define the functionality of the device. Typically, there is a one-to-one correlation between a function and an interface. However, certain devices expose multiple interfaces related to one function." So let's say I want to exploit this new WebUSB API. If I infect your computer with malware that installs a second USB driver for the hardware I want access to, and this second driver has support for WebUSB, I could theoretically control the driver being used by making a WebUSB request for the device, thereby exposing the hardware for further exploits.
- icebraining 11y ago
  This is what Raymond Chen calls "being on the other side of the airtight hatchway". If you can install an USB driver on my machine, it's because you can run native code on my machine, and so you can use that to talk to the USB device without requiring WebUSB.
  - ZenoArrow 11y ago
    The difference between using the malware itself to communicate via the web and using WebUSB to do so would be in malware detection. If an unidentified EXE hidden in your Windows partition is communicating via the web that's going to look a lot more suspect than a driver which is trusted by the system. The malware that installed the driver could remove itself after installing the driver, taking out another way to track it down.
    - 11y ago
makomk 11y ago
In order for this to be even vaguely secure, every single device that declares support for WebUSB has to refrain from allowing firmware updates over WebUSB despite how incredibly convenient this is, and despite how much of a support nightmare it would be to roll out bugfixes to users without it, and despite them being developed by hardware manufacturers who generally don't give a fuck about security. I can't see this happening. (Allowing remote firmware updates effectively gives full remote code execution on the host PC to the website behind the device, since it can then emulate USB input devices.)
- icebraining 11y ago
  Oh, I don't disagree; I would bet some of those devices will get owned. My only hope is that the manufacturers will set the "origin allowed" field that says what domains may access the devices.