

When people ask for security holes as features: Privileged execution - edw519
http://blogs.msdn.com/oldnewthing/archive/2009/09/24/9898728.aspx

======
tptacek
This post is good on security and bad on OS design. The last 10 years of OS
design has in large part been about finding small facets of the kernel that
can be exported to userland via apertures and very-low-level programming
interfaces.

The answer "no you can't have these privileged instructions" is incomplete;
it's missing "but here's the API that safely wraps them."

Problems like this are part of what makes OS security so interesting. Good
security isn't about saying, "no, moron, if I give you that capability you'll
be able to own up the kernel." In fact, security is almost never about saying
"no". When you tell someone "the only way to build this feature is by writing
a driver", you're asking them to write kernel code instead of userland code,
which makes security _worse_.

~~~
mquander
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
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
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
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
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.

------
pmichaud
This extends to other areas as well. I was shocked the first time I found an
"enterprise" app with an interface for executing arbitrary SQL with full
permissions. The shock wears off when you see it over and over. It's nuts.

~~~
tptacek
Amen. I'm surprised by how many developers think this is a totally reasonable
debugging feature, and think that nobody is going to find it because it's in a
hidden diagnostic support section of the application. Note to product
developers: we always find these things.

