Hacker News Reader

Comment by arghwhat | Hacker News Reader

Uhm. If you can't trust them to write a user-mode program without messing up security this badly, you absolutely can't trust them to write a kernel-mode driver without completely screwing everything up. Not to mention one that is automatically downloaded and installed whenever something shows up claiming to be a particular vendor/product ID!

View on HN

It has nothing to do with 'trusting them' and everything to do with the threat model because it significantly increases the attack surface area.

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.

I think the OP's point is that any malicious code residing in the USB driver has access to a much larger attack surface in kernel space than the UI app running in userspace.

If I were attacking the system along this vector, my exploit would sit in the USB driver, not the UI code.

Same. Was wondering when the conversation would get around to this.

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.

This isn't about malicious code in the drivers.

And once malicious code is in kernel space it wouldn't even need access to an attack surface.

I expect the developers who write the kernel mode drivers to be much more competent and senior than those who write the flashy, slow GUIs that come with them. Yes, naive assumption, but still!

I wish that were the case—I also wish it were the case that “senior” meant “competent.” Judging by the number of device drivers I’ve had cause serious problems, especially with consumer gaming hardware (as is the case here), I don’t think it’s safe to make any assumptions about the quality of drivers.

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.

It's also not about seniority or competence. Writing kernel mode drivers is being given the task of juggling running chainsaws with real chains while on a balancing board. "Success" is declared when you're able to do this in a lab without there being an issue, ignoring the fact that in the real world there are dodgeballs being thrown at you. Also, no one I've ever worked with writing them has ever wanted to maintain & improve the quality of the drivers they wrote - they wanted to move on to "interesting" work as quickly as possible. This includes myself. The work isn't interesting, fun & usually not important to the business.

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.

They don't even need to buy the device, they just need something presenting that PID/VID.

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.

Speaking as someone who worked at major software companies, on projects which included multiple kernel drivers:

You are sorely mistaken.

I would say that the higher you get up the privilege level tree, the worse the software becomes. The people writing legacy BIOS extensions are the absolute bottom of the barrel.

In modern software development, this is usually a task for the junior engineer as it's code the client never sees. Only in specific industries where the client is also highly technical (e.g. a data-acquisition component in an instrument) where the quality of the low-level code matters, would it be someone senior. In those cases, it usually matters a lot more than the UI.

Exhibit A: Turing-complete font hinting language evaluated in kernel mode. Found to be exploitable.

https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...

Not at all. The only thing going in favor of the kernel mode drivers is that they have to pass Microsoft's approval process.

I still don’t get why companies who design hardware a so poor at writing drivers/supporting software. They design and test hardware, because recalls are expensive, but somehow feel like shipping shitty software is just fine.

Why is it so hard to priorities good drivers? Or is it just impossible to hire good driver developers?

Well there's 1) The businesses that sell hardware are run by people whose expertise is hardware, not software and 2) the type of people who have the right combination of skills and inclination to write drivers are rare but also can earn a lot more doing other type of software (hardware margins aren't all all that high compared to software).

> you absolutely can't trust them to write a kernel-mode driver without completely screwing everything up

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 driver is generally written by people whose task is to get the device to work

the development of the application is driven by concerns with UX trendiness, brand management, marketing, telemetry, etc.

This seems to work for Linux kernel just fine when every pull request is audited.

This is Windows where kernel drivers are proprietary and written by random companies that do not care about anything but shipping things. The same company that messed up completely in usermode.

Would be an interesting step, if Microsoft would only allow open source drivers into Windows Update.

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.

Reply on news.ycombinator.com