5 ms·

So I know of a very popular keyboard controller than can be made to run unsigned code by sending it the right HID data. Said code persists after reboot. Pleas

So I know of a very popular keyboard controller than can be made to run unsigned code by sending it the right HID data. Said code persists after reboot. Please point out if this attack is not viable: Ask for permission to use your keyboard. No matter how scary the warning, non-technical users will allow a website to use the keyboard because "of course it needs a keyboard" Upload a malicious payload to keyboard. Remember, now it can present itself as any USB device. Or maybe stay simple with a keylogger, maybe with heuristics to get juicy data (what are the first 20 characters typed at boot and after "www" is typed) Game over?

zamadatix 7y ago
Nope, the first 3 (plainly written) sections of the standard will tell you why if you're curious https://wicg.github.io/webusb/#introduction https://wicg.github.io/webusb/#introduction The upcoming WebHID API considers and mitigates this attack as well https://wicg.github.io/webhid/#introduction https://wicg.github.io/webhid/#introduction
- BoorishBears 7y ago
  Excuse me, what? Please explain your reasoning. (And yes I read the section 3 of the standard before writing the comment above, see my other comment in this thread) WebHID even says it more plainly: > In general, these types of attacks are device-specific and cannot be mitigated at the API level. Both documents you linked literally go: "We know these attacks exist, we don't care as long as we show a prompt, device manufacturers fix your shit it's not our problem" - I can't reply for some reason but: I didn't see any mention of HID devices not being listed, not was it immediately apparent that a HID device would already be held in the kernel context I also still don't see blocking input from trusted devices, I see the same language I called out: "Device manufacturers should watch out" - "I think it works like this, why doesn't it" is a great way to learn things, except when the reply is a low effort: "here's that thing you read, did you actually read it?"
  - zamadatix 7y ago
    Going with the good faith assumption you read it trying to find why instead of why not in the WebUSB standard you can find this paragraph under 3.1 Abusing Access to a Device: "Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface." I.e. the keyboard couldn't be claimed even if you managed to get it to list as it's claimed via the OS HID driver so can't be claimed via the userspace driver. HID devices are also hid from the listing (no pun intendend) which is what resulted in the WebHID standard in the first place. For WebHID understand it's an early draft and that the method described in section 3.1 of blocking access to HID devices that can generate trusted input is actually the go forward implementation plan not merely a suggestion. . I don't mind discussing WebUSB further but not if the conversation is just going to be in a "I thought it might work this way, show me the line that says it isn't" way. There are many blog posts that cover it better than I could anyways (such as https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.html https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.h...)
    - jdsully 7y ago
      That may be obvious if your used to USB, but it's actually quite a leap otherwise. An explanation in your original post would have gone a long way.
      - zamadatix 7y ago
        Just to clarify I'm no expert in USB in any way, shape, or form and do not wish to claim to be. I have never worked with USB (beyond quite literally sticking a device in the port or reading about which USB storage drive to get) prior to reading the original article this post linked to and don't want to give the false impression I'm an expert in the field because I've read a few documents/demos followed by a couple of blog posts after.
floatingatoll 7y ago
Which keyboard controller, precisely? Have you reported the issue to the maker? Has the responsible disclosure window elapsed?

zamadatix 7y ago

Nope, the first 3 (plainly written) sections of the standard will tell you why if you're curious https://wicg.github.io/webusb/#introduction https://wicg.github.io/webusb/#introduction The upcoming WebHID API considers and mitigates this attack as well https://wicg.github.io/webhid/#introduction https://wicg.github.io/webhid/#introduction

BoorishBears 7y ago
Excuse me, what? Please explain your reasoning. (And yes I read the section 3 of the standard before writing the comment above, see my other comment in this thread) WebHID even says it more plainly: > In general, these types of attacks are device-specific and cannot be mitigated at the API level. Both documents you linked literally go: "We know these attacks exist, we don't care as long as we show a prompt, device manufacturers fix your shit it's not our problem" - I can't reply for some reason but: I didn't see any mention of HID devices not being listed, not was it immediately apparent that a HID device would already be held in the kernel context I also still don't see blocking input from trusted devices, I see the same language I called out: "Device manufacturers should watch out" - "I think it works like this, why doesn't it" is a great way to learn things, except when the reply is a low effort: "here's that thing you read, did you actually read it?"
- zamadatix 7y ago
  Going with the good faith assumption you read it trying to find why instead of why not in the WebUSB standard you can find this paragraph under 3.1 Abusing Access to a Device: "Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface." I.e. the keyboard couldn't be claimed even if you managed to get it to list as it's claimed via the OS HID driver so can't be claimed via the userspace driver. HID devices are also hid from the listing (no pun intendend) which is what resulted in the WebHID standard in the first place. For WebHID understand it's an early draft and that the method described in section 3.1 of blocking access to HID devices that can generate trusted input is actually the go forward implementation plan not merely a suggestion. . I don't mind discussing WebUSB further but not if the conversation is just going to be in a "I thought it might work this way, show me the line that says it isn't" way. There are many blog posts that cover it better than I could anyways (such as https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.html https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.h...)
  - jdsully 7y ago
    That may be obvious if your used to USB, but it's actually quite a leap otherwise. An explanation in your original post would have gone a long way.
    - zamadatix 7y ago
      Just to clarify I'm no expert in USB in any way, shape, or form and do not wish to claim to be. I have never worked with USB (beyond quite literally sticking a device in the port or reading about which USB storage drive to get) prior to reading the original article this post linked to and don't want to give the false impression I'm an expert in the field because I've read a few documents/demos followed by a couple of blog posts after.

floatingatoll 7y ago

Which keyboard controller, precisely? Have you reported the issue to the maker? Has the responsible disclosure window elapsed?