3 ms·

Well, what that really means is "the only way to build this feature is by writing code that gets signed, either by you or by some trustworthy guy." The trust i

Well, what that really means is "the only way to build this feature is by writing code that gets signed, either by you or by some trustworthy guy." The trust is supposed to come from the code signing, not from the fact that it's a driver and not a user-mode app.

tptacek 17y ago
Code signing is rubber chicken security. It sure sounds good. But the threat with code like this is incompetence, not malice, and nobody --- nobody --- has the resources to audit every Windows driver, or even every OSX driver for that matter. The problem here is that the interface the MSDN blogger is talking about is brittle. "You can't have those instructions unless you write a driver". Well, they're going to get the instructions, genius. They have a business driver, and business trumps principles every time. So they're going to go through whatever dance MSFT requires this year to ship as a driver, and the kernel's going to get one more piece of incompetent driver code. Maybe I'm missing some backstory here, but that's my read.
- roc 17y ago
  Better that one vendor incompetently write a driver than have Microsoft open the floodgates with a shockingly insecure API 'feature' (again). It's much easier to replace third parties than the OS.
  - tptacek 17y ago
    I think pretty much all the OS vendors have equally bad track records with kernel/userland interface design. But, having done a few device driver audits, I respectfully disagree, and submit to you that if your job exposed you to 3rd party driver code, you too would rather MSFT took a risk on kernel APIs than increase the number of drivers.
    - roc 17y ago
      Don't get me wrong: I would absolutely prefer MSFT write a proper API to handle the necessary requests, rather than leave it to vendors to write drivers. But in reality no API will cover every corner case. And if the choice is between vendors writing drivers to cover those situations, or Microsoft leaving a 'hole' in the API which allows arbitrary instructions to be passed through, I'll take vendor drivers every time.

tptacek 17y ago

Code signing is rubber chicken security. It sure sounds good. But the threat with code like this is incompetence, not malice, and nobody --- nobody --- has the resources to audit every Windows driver, or even every OSX driver for that matter. The problem here is that the interface the MSDN blogger is talking about is brittle. "You can't have those instructions unless you write a driver". Well, they're going to get the instructions, genius. They have a business driver, and business trumps principles every time. So they're going to go through whatever dance MSFT requires this year to ship as a driver, and the kernel's going to get one more piece of incompetent driver code. Maybe I'm missing some backstory here, but that's my read.

roc 17y ago
Better that one vendor incompetently write a driver than have Microsoft open the floodgates with a shockingly insecure API 'feature' (again). It's much easier to replace third parties than the OS.
- tptacek 17y ago
  I think pretty much all the OS vendors have equally bad track records with kernel/userland interface design. But, having done a few device driver audits, I respectfully disagree, and submit to you that if your job exposed you to 3rd party driver code, you too would rather MSFT took a risk on kernel APIs than increase the number of drivers.
  - roc 17y ago
    Don't get me wrong: I would absolutely prefer MSFT write a proper API to handle the necessary requests, rather than leave it to vendors to write drivers. But in reality no API will cover every corner case. And if the choice is between vendors writing drivers to cover those situations, or Microsoft leaving a 'hole' in the API which allows arbitrary instructions to be passed through, I'll take vendor drivers every time.