Microsoft BlueHat Security Conference

[mmiller at hick.org (mmiller at hick.org)]

This appears to be flamebait, but I can't resist...

On Mon, Jun 20, 2005 at 08:25:51PM -0700, Tomas L. Byrnes wrote:
>  
> I think this is an oversimplification. When MS made the browser the
> shell, with IE 4, everyone and their brother screamed that this was a
> guaranteed security hole. It doesn't take a genius to see that
> Browser=Shell and everyone runs as local admin is a wide open door for
> problems.
>
> MS didn't do that for the sake of features, they did it as a shortcut to
> dominating the browser market, since they couldn't get a functioning
> independent browser out fast enough, and tying the browser tightly to
> the OS meant that everyone would have to use IE at least some of the
> time, and that it would be faster and could do things that an
> application based browser couldn't (ActiveX, another security disaster,
> designed to kill Java). The result has been the plethora windows
> security flaws.

ActiveX has its roots in COM which has its roots in OLE which was around
well before java.  Whether or not it can be construed as a so-called
java-killer in present times is arguable, but I believe it's safe to say
that the original architectural designs upon which it is founded were in
no way intended to be a java-killer, but rather a novel approach to
dynamic linking, among other much cooler things.

> I think it is a bit disingenuous to buy, and then sell, MS spin on their
> security problems hook-line-and-sinker. A lot of the problems have
> nothing to do with the developers, or the way they develop the code, but
> are a direct result of business decisions that have caused the creation
> of monolithic code with root-level access.

Not to say that it's an excuse, but this is true in all businesses.
There are rare exceptions to the rule that business needs will not out
weigh what developers would like to have done given ample time and
money.  You can't compare apples to oranges.  Linux and other free
operating systems don't operate on a timeline that is driven by a bottom
line.  That's a great thing when you can achieve it, but it's obvious
that businesses like Microsoft cannot, and as such you run into cases
where business needs have more weight than those of the developers, and
you weigh your risks.  Again, I'm not a fan of that, and I hate being
rushed by business needs, but nevertheless it IS a valid reason.

> Windows security problems are architectural, not implementation. A lack
> of compartmentalization, object and component oriented architecture, and
> the total absence of inheritance, precedence, and processes being
> bounded to the least privilege, and in no case being able to elevate
> privilege beyond that of the parent (since there is no parent, this
> doesn't exist), is the root cause of the vulnerabilities, IMO. 

I'll take this phrase by phrase, though it seems to be primarily a
mismash of technical jargon thrown together:

Comparmentalization:

Every logical API is isolated from one another.  The native API
abstraction layer and library loading facilities are found in ntdll.dll,
then the core operating system API that's layered on top of the native
API is found in kernel32.dll, on top of which most every other
system-supplied API is built in one form or another.  From there it
becomes a tree of dependencies that are, generally speaking, quite well
thought out.  Aside from user-mode, kernel-mode is quite well
compartmentalized too.  This is all quite well documented.

Object and component oriented architecture:

I'm afraid this cannot be further from the truth.  Objects are
everything at Microsoft, even in C.  While you may not consider an
opaque handle an object, it's nonetheless associated with one under the
hood.  There are so many examples of object and component design that
all I need do to cite specific examples is point you in the direction of
the existing documentation on MSDN.

Total absence of inheritance:

What does this mean?  Are you referring to code re-use?  Handle
inheritance?  Object security?

Processing being bounded to the least privilege:

In fact, they are.  While your point is well taken that many people run
with administrative privileges, they are nonetheless bounded to the
fewest number of privileges that an administrator has (yes, their are
privileges that administrator doesn't have by default).  The same is
true for all objects.  The object security model present in Windows NT
is quite robust, though often a pain to deal with at some levels.

> MS should follow Apple's lead, use BSD as the underlying OS, and make $
> off apps and interfaces.

Really, you're advocating the use of an out-dated BSD kernel over
something that was so well designed by David Culter et al. back in 1985
that the core NT kernel remains intact without ANY rewrites or
redesigns?  Imagine, for a moment, the amount of foresight they had when
designing this stuff.  It really is quite incredible.  Anyway...

Consider me trolled.