Slashdot Mirror
Microsoft's Larry Osterman On Threat Modeling
Schneier has pointed out an excellent series of blog posts about threat modeling by Microsoft's Larry Osterman. The series focuses on the PlaySound API as an example. "As you go about filling in the threat model threat list, it's important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team. At the end of the day, this process is about ensuring that our customer's machines aren't compromised. When we're deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage."
Funny that "threat mitigation" doesn't exist in the aerospace industry...
What would you call passing through airport security to fly on a passenger aircraft?
Airplanes typically don't stand up to serious attacks. I'm not sure where you're trying to go with this analogy.
For high reliability code, you write code on the assumption that other code may have problems. You write code defensively. For any kind of complex system, people will make mistakes. Thus you have to continually verify program integrity and security in a multiply redundant manner. You don't wait until a trust barrier is crossed.
For example, if I have an application controlling a power plant, even if the computer is already running "foreign" code at my privilege level, the control application may still be up. It isn't until the foreign code impacts on the control application that a major security problem exists. Unfortunately, Microsoft makes it easy for the foreign code to impact the control application. The code could consume all available CPU resources, it can consume almost all available disk bandwidth, it can run Windows out of Virtual Memory or Handles. None of these attacks are easily blocked by existing Windows security. Of course, when the ability to inject code into the control system is considered, rogue program security gets worse.
Microsoft's threat model does not even consider the effect of "friendly" code, to impact on critical code. If you can't detect adverse interactions with friendly code, then I really question the ability to survive malicious code impacts.
At least two levels of redundancy are required. Malicious code almost always starts as an unexpected consequence of a friendly application, and the first level of redundancy is that the authors write the friendly application in a secure manner. In practice, relying solely on this level of redundancy is fraught with peril. As such, additional levels of redundancy are required. A key second level of redundancy is that even if a friendly application runs amok, the control system should keep running. This implies isolation between applications running at the same privilege level.
The intent of multi-tasking operating systems is to prevent applications at the same privilege level from affecting each other both directly and indirectly. Applications should not be able to affect each other either directly (application to application) or indirectly (via slowing the computer to a crawl.) By only looking at trust escalation issues, Microsoft has a key areas of redundancy and security.
If it's so idiotic to "integrate the browser into the OS", then why does Apple do it with OSX and why does the KDE team do it with their desktop environment?
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
One of the important jobs of any operating system is to isolate and protect applications from one another. To assume the so-called "Immutable Law #1" is to pretend that this responsibility doesn't exist.
I'm sure they've heard of encapsulation, right? Defense in depth? How about the principle of least privilege? The thinking behind Law #1 -- that when a user runs a program, that program automatically gets full rights to pull all the user's privileges out of thin air and exercise them in whatever way it wants -- runs counter to all of these fundamental security concepts.
A revision of the Law that's somewhat closer to the truth would be something like: "If a bad guy can persuade you to run his program on your computer, and your operating system allows that program to damage the system, other programs, or your data, it's not your computer anymore." The operating system does not get a free pass.
Which ones? I just tried unsuccessfully to access the web through Finder, and when I try to access the local file system through Safari it was smart enough to call Finder, but doesn't access the file system itself.
Explorer doesn't "access the web", either, it just loads up the IE components inside the Explorer window (in the same way you can embed an Excel spreadsheet into a Word document and it fires up Excel from within Word).
I mentioned KDE in my original post, which does integrate the browser and UI tools, but since that's a desktop, not an OS, it's a different matter.
No, it's exactly the same "matter". You are creating a false dichotomy.
I suppose it's arguable that "Explorer" is only a UI level system in Windows, but that seems disingenuous since unlike in Linux Windows has only one supported UI, and the UI is coded and provided by the OS maker as part of the OS.
You are conflating a marketing issue (Windows only comes with one shell) with a technical issue (how the various components run and interact).
It's also true that unlike in KDE where nothing can execute with elevated privileges without a password being entered (either the user's password through sudo or the root password through an su), Explorer can and has been known to execute code as 'system' without checking first.
That's a pretty serious bug. Evidence ?
I'm also not clear on how two different executables that access the exact same dlls, and perform in an identical fashion are not the same thing. The fact that Internet Explorer loads the "bookmark" module, and the "Google Search Bar" module, and Windows Explorer loads the "jump around the file system" module doesn't make them different software. They are functionally identical except for a few modules that are loaded differently depending on how they are called.
Try thinking about how many different programs do exactly the same thing using glibc (because, well, that's the point of having a shared library to do it).