Metasploit mailing list archives
Microsoft BlueHat Security Conference
From: mmiller at hick.org (mmiller at hick.org)
Date: Tue, 21 Jun 2005 00:01:24 -0500
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.
Current thread:
- Microsoft BlueHat Security Conference H D Moore (Jun 20)
- <Possible follow-ups>
- Microsoft BlueHat Security Conference Tech (Jun 20)
- Microsoft BlueHat Security Conference H D Moore (Jun 20)
- Balasan: Re: [framework] Microsoft BlueHat Security Conference Sugiowono Tjhin (Jun 20)
- Microsoft BlueHat Security Conference H D Moore (Jun 20)
- Microsoft BlueHat Security Conference Tomas L. Byrnes (Jun 20)
- Microsoft BlueHat Security Conference mmiller at hick.org (Jun 20)