For anyone else reading this who’s feeling smug because they would never buy such a device: you don’t need to; only the attacker needs to. Windows will happily download and install the drivers automatically the first time the device is plugged in.
In this case, why does a mouse driver need to live in the kernel in the first place? Microsoft should be improving the HID layer to make that unnecessary.
Foe a $2 example, see: https://github.com/chris408/digispark-usbkey-board (PID/VID set here: https://github.com/chris408/digispark-usbkey-board/blob/6f0a...). And yes, it can be much, much smaller than this.
You are sorely mistaken.
https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...
There could be another option: If you want to ship it without exposing the source, you need your drivers vetted by some third party that has access to the code.
Just because I want to grant system access to a relatively simply USB driver doesn't mean I want to grant the same access to a 150MB UI app.
If I were attacking the system along this vector, my exploit would sit in the USB driver, not the UI code.
You could take advantage of being SYSTEM much earlier along this cycle and still take control of the computer. This is actually a very nasty bug in how arbitrary code can be run at SYSTEM level when inserting a usb device.
And once malicious code is in kernel space it wouldn't even need access to an attack surface.
Why is it so hard to priorities good drivers? Or is it just impossible to hire good driver developers?
Absolutely. The overwhelming majority of hardware companies are not competent enough to write drivers of any kind. They're not even competent enough to write user space software. They treat software as a cost center. To them software's just wasted money, to be made as cheaply as possible and only because they have to.
Linux kernel is great as a litmus test. If a company can't get a driver into the kernel it shouldn't be trusted with writing drivers of any kind.
the development of the application is driven by concerns with UX trendiness, brand management, marketing, telemetry, etc.
The major difference between user mode programs and kernel mode programs is security and stability (at least in this context). Things in kernel mode have basically no restrictions on what they can do, from a security sense. Things in kernel mode can also crash the thing they're part of: the kernel. That's a blue screen (or cyan, now). One of the reasons those blue screens are so much less common is that Microsoft really pushes OEMs to make userspace drivers. If they die, they just get restarted, no need to crash the whole OS.
The other issue is of installing user-facing utilities alongside the driver. That needs to stop. It's orthogonal to the kernel vs user mode issue though, because Razer can make their UI run in kernel mode. It's a horrible, terrible idea that no one will enjoy, but they can. And really, we want the drivers to run in user space too if we can.