Larry Osterman's WebLog : Software Engineering

I can make it arbitrarily fast if I don’t actually have to make it work.

LarryOsterman — Wed, 30 Sep 2009 00:49:37 GMT

Digging way back into my pre-Microsoft days, I was recently reminded of a story that I believe was told to me by Mary Shaw back when I took her Computer Optimization class at Carnegie-Mellon…

During the class, Mary told an anecdote about a developer “Sue” who found a bug in another developer’s “Joe” code that “Joe” introduced with a performance optimization. When “Sue” pointed the bug out to “Joe”, his response was “Oops, but it’s WAY faster with the bug”. “Sue” exploded “If it doesn’t have to be correct, I can calculate the result in 0 time!” [1].

Immediately after telling this anecdote, she discussed a contest that the CS faculty held for the graduate students every year. Each year the CS faculty posed a problem to the graduate students with a prize awarded to the grad student who came up with the most efficient (fastest) solution to the problem. She then assigned the exact same problem to us:

“Given a copy of the “Declaration of Independence”, calculate the 10 most common words in the document”

We all went off and built programs to parse the words in the document, inserting them into a tree (tracking usage) and read off the 10 most frequent words. The next assignment was “Now make it fast – the 5 fastest apps get an ‘A’, the next 5 get a ‘B’, etc.”

So everyone in the class (except me :)) went out and rewrote their apps to use a hash table so that their insertion time was constant and then they optimized the heck out of their hash tables[2].

After our class had our turn, Mary shared the results of what happened when the CS grad students were presented with the exact same problem.

Most of them basically did what most of the students in my class did – built hash tables and tweaked them. But a couple of results stood out.

The first one simply hard coded the 10 most common words in their app and printed them out. This was disqualified because it was perceived as breaking the rules.
The next one was quite clever. The grad student in question realized that they could write the program much faster if they wrote it in assembly language. But the rules of the contest required that they use Pascal for the program. So the grad student essentially created an array on the stack and introduced a buffer overflow and he loaded his assembly language program into the buffer and used that as a way of getting his assembly language version of the program to run. IIRC he wasn’t disqualified but he didn’t win because he circumvented the rules (I’m not sure, it’s been more than a quarter century since Mary told the class this story).
The winning entry was even more clever. He realized that he didn’t actually need to track all the words in the document. Instead he decided to track only some of the words in the document in a fixed array. His logic was that each of the 10 most frequent words were likely to appear in the first <n> words in the document so all he needed to do was to figure out what "”n” is and he’d be golden.

So the moral of the story is “Yes, if it doesn’t have to be correct, you can calculate the response in 0 time. But sometimes it’s ok to guess and if you guess right, you can get a huge performance benefit from the result”.

[1] This anecdote might also come from Jon L. Bentley’s “Writing Efficient Programs”, I’ll be honest and say that I don’t remember where I heard it (but it makes a great introduction to the subsequent story).

[2] I was stubborn and decided to take my binary tree program and make it as efficient as possible but keep the basic structure of the solution (for example, instead of comparing strings, I calculated a hash for the string and compared the hashes to determine if strings matched). I don’t remember if I was in the top 5 but I was certainly in the top 10. I do know that my program beat out most of the hash table based solutions.

Digging into the history bin (AKA: Microsoft Developer says that Windows is useless)

LarryOsterman — Tue, 01 Sep 2009 21:49:25 GMT

As I was writing my “25 years of Larry’s history at Microsoft in 1 year chunks” blog posts, I spent a fair amount of time digging through my email archives (trying to figure out exactly what happened at what time). During this, I ran into a link to a post I’d made on the Info-IBMPC mailing list mailing list back in 1992:

Date: Thu, 12 Mar 92 12:44:39 PST
From: lar...@microsoft.com
Subject: What do you do with your windows? (V92 #36)

|| >From: m...@Violin.CC.MsState.Edu (Mubashir Cheema)

|| I recently acquired Windows 3.0 and I don't seem to understand one
|| thing. What is it for? What do I do with it? What major advantage
|| does it have over Dos? (I don't see any except being able to use mouse
|| and also the thing is bit more colorful) I think it was made for lazy
|| people who couldn't learn couple of DOS commands.

|| Don't tell me I could multi-task with it. I've been using Amigas
|| extensively

I've got to jump in here, even though I suspect that there will probably be some form of an "official" response from MS if anyone in the DOS/Windows group is listening...... :)

I'm going to be brutally honest about this one. Basically, Windows by itself IS pretty useless. The thing that makes Windows great is the same thing that has made DOS the most popular operating system in history. It's the applications that are available for it.

GUI's (Graphical User Interfaces) have been proven to be significantly easier for users to understand for beginning users, and are arguably the wave of the future. I don't know of a significant operating system being introduced for the PC market that doesn't have a GUI available on it, be it PM, X, GEM, or Windows. Windows is arguably the best GUI available for DOS based on what I consider the most significant criteria: What applications are available for the platform.

Consider the list of available windows apps: Excel, WinWord, PageMaker, Corel Draw, WordPerfect, Lotus 123, etc just to name a couple off the
top of my head.

You also hit on one of the significant reasons to use Windows - Multi-tasking.

Windows is a non pre-emptive multi-tasking operating system. On a 386, it does an ok job of multi-tasking multiple DOS applications, but on a
286 it functions as a simple task switcher like DOS 5 does. It really shines when multi-tasking Windows applications however.

In addition, when you couple the multi-tasking capabilities of Windows with a windows mechanism known as DDE (for Dynamic Data Exchange), you
can generate some truly incredible synergy between Windows applications. With Win 3.0/Win 3.1 Microsoft has introduced a concept
known as OLE (Open Linking and Embedding) which allows you to cut and past from multiple "applets" allowing applications to take advantage of
the capabilities of other shipped applications. This allows an applet like an equation editor to manage all the information about formatting
an equation even when the equation is embedded in a word document. With OLE, you can simply double-click on the object and bring up the
"agent" that manages it (in my example, the equation editor).

For application developers, Windows gives developers the ability to develop their applications without knowing anything about the
underlying hardware of the machine - a windows application that runs on a machine with a CGA adapter will also run on a machine with a graphics
accelerator that runs in 1024x1024 with 24 bits of color.

In addition, when you write an application for windows, your application instantly will support literally hundreds of printers
transparently - Windows does all the work for you.

To re-iterate, Windows as a stand-alone product is not extraordinarily interesting - there are lots of productivity packages that provide
similar functionality to users, the real benefit of Windows is the applications that run on it.

I will also point out that there are more than 5000 Windows applications available today and still more will come out with Win 3.1.
The available windows applications span all ranges of applications from games (Microsoft's Entertainment pack, Berkley-Soft's After Dark, and
Sierra's Laffer Utilities for Windows) to Spreadsheets (Microsoft Excel, Lotus 1-2-3) to Word processors (Microsoft Word For Windows,
Lotus Ami), to Desktop publishing (Aldus Pagemaker, Microsoft Publisher), to presentation graphics (Microsoft Powerpoint), to
development tools (Microsoft Visual Basic) etc......

Larry Osterman

Disclaimer: The opinions above are my own. They are not necessarily the same as those of Microsoft. I only work here.

Remember that this was written back in 1992 after Windows 3.0 had come out but before Windows 3.1. There was no Win32, no web browser, no multimedia support, none of the things that we all take for granted in a modern system. Back then a display card that supported 1Kx1K with 24bit color was considered a monster display card (and hard disks still came in “megabytes” – I remember buying a 2G hard disk back then for about a thousand dollars).

Reading this again, I find it vaguely funny that in many ways my feelings about Windows haven’t really changed that much in 18 years – the value of the Windows platform is STILL the applications available for that platform (although the number of applications has grown from the 5000 or so back in 1992 to several million applications).

Thinking about Last Checkin Chicken

LarryOsterman — Wed, 01 Jul 2009 01:34:04 GMT

Raymond Chen’s post today started me thinking about “Last Check-in Chicken” again. Back in the says when we were close to shipping Windows Vista, I wrote about ”Last Check-in Chicken”. What I didn’t mention was who ultimately won the game for Windows Vista.

It turns out that the very last change to Windows Vista was actually made by one of the developers on the sound team.

When you reach the last few days of a project, the bar for taking changes is insanely high – the teams which approve changes to the product get increasingly more conservative about taking changes – every change taken is an opportunity for regression and resets some amount of the testing which has gone before. So the number of bugs that are accepted towards the end of a product gets smaller and smaller. You can think of the ability to take bugs as a series of ever increasingly high barriers – it starts fairly low – just about any bug fix will be accepted into the tree. This is the normal state during most of product development. As time goes on and the team gets closer to shipping, the bug bar gets raised and the bugs that are considered are only those that are going to affect customers directly (as opposed to those bugs found during testing won’t necessarily be encountered by customers). Then the bar gets raised again (and again, and again) until eventually it gets to the point where the only bugs that are accepted are “recall class” bugs[1].

The idea behind a “recall class bug” is that it’s is a bug that is so bad that we’d be willing to call the manufacturer and pull the product off the assembly line (at a cost of millions of dollars) to fix. These are the worst-of-the-worst bugs, and typically involve major scenarios not working. When the bug bar is at “recall class only”, there are typically only two or three bugs that are considered each day across all of Windows and even then most of the bugs brought up to the triage team aren’t accepted.

At some point the bug bar gets beyond even “recall class only” – this is when you’re REALLY close to being done (typically the last two or three days of a product). Normally builds of the product are done daily because there are one or two “recall class” bugs still being accepted. But eventually all those bugs are fixed and the build team stops doing daily builds because there have been no changes since the previous build. The test team is hard at work doing it’s final sign-off of the bits and everybody is on tenterhooks waiting for the final build to come out. When you’re at this stage of the product, every once in a while a change comes in that would be really nice to have because it fixes a critical issue with an important scenario, but it’s just just not important enough to justify cracking open the bits to take the change. Raymond calls these type of changes “Remora Check-ins”. The idea is that if another bug was discovered during the final testing phase that forced us to rebuild the system, we would take these “Remora Check-ins” along for the ride.

In our case, the change we made was a Remora check-in – it was an important bug, but it wasn’t important enough to justify resetting the final test pass. But someone else’s component had a critical bug that HAD to be fixed and our change came along for the ride (and no, I don’t remember exactly what either of the changes were, I just know that our check-in was chronologically the last one made).

Nitpickers corner: None of the information in this post should be particularly controversial – much of what I’ve described here is software engineering 101. There’s always a bar for taking bug fixes in every product – if there weren’t, you’d never ship the product (for example, the Mozilla Foundation shipped Firefox version 3.5 today (congrats!) and they still have several dozens of critical bugs active in their database – I’m sure that these are all bugs that didn’t meet their bug bar). Heck, there’s even a book that’s all about the process of shipping NT 3.1 that covers much of this information.

----

[1] In the past these bugs would be called “Show Stoppers”.

Everyone wants a shiny new UI

LarryOsterman — Thu, 29 Jan 2009 08:24:49 GMT

Surfing around the web, I often run into web sites that contain critiques of various aspects of Windows UI.

One of the most common criticisms on those sites is "old style" dialogs. In other words, dialogs that don't have the most up-to-date theming. Here's an example I ran into earlier today:

Windows has a fair number of dialogs like this - they're often fairly old dialogs that were written before new theming elements were added (or contain animations that predate newer theming options). They all work correctly but they're just ... old.

Usually the web site wants the Windows team update the dialog to match the newest styling's because the dialog is "wrong".

Whenever someone asks (or more often insists) that the Windows team update their particular old dialog, I sometimes want to turn around and ask them a question:

"You get to choose: You can get this dialog fixed OR you can cut a feature from Windows, you can't get both. Which feature in Windows would you cut to change this dialog?"

Perhaps an automotive analogy would help explain my rather intemperate reaction:

One of the roads near my house is a cement road and the road is starting to develop a fair number of cracks in it. The folks living near the road got upset at the condition of the road and started a petition drive to get the county to repair the road. Their petition worked and county came out a couple of weeks later and inspected the road and rendered their verdict on the repair (paraphrasing): We've looked at the road surface and it is 60% degraded. The threshold for immediate repairs on county roads is 80% degradation. Your road was built 30 years ago and cement roads in this area have a 40 year expected lifespan. Since the road doesn't meet our threshold for immediate repair and it hasn't met the end of its lifespan, we can't justify moving this section of road up ahead of the hundreds of other sections of road that need immediate repair.

In other words, the county had a limited budget for road repairs and there were a lot of other sections of road in the county that were in a lot worse shape than the one near my house.

The same thing happens in Windows - there are thousands of features in Windows and a limited number of developers who can change those features. Changing a dialog does not happen for free. It takes time for the developers to fix UI bugs. As an example, I just checked in a fix for a particularly tricky UI bug. I started working on that fix in early October and it's now January.

Remember, this dialog works just fine, it's just a visual inconsistency. But it's going to take a developer some amount of time to fix the dialog. Maybe it's only one day. Maybe it's a week. Maybe the fix requires coordination between multiple people (for example, changing an icon usually requires the time of both a developer AND a graphic designer). That time could be spent working on fixing other bugs. Every feature team goes through a triage process on incoming bugs to decide which bugs they should fix. They make choices based on their limited budget (there are n developers on the team, there are m bugs to fix, each bug takes t time to fix on average, that means we need to fix (m*t)/n bugs before we can ship).

Fixing theming bug like this takes time that could be spent fixing other bugs. And (as I've said before) the dialog does work correctly, it's just outdated.

So again I come back to the question: "Is fixing a working but ugly dialog really more important than all the other bugs?" It's unfortunate but you have to make a choice.

PS: Just because we have to make choices like this doesn't mean that you shouldn't send feedback like this. Just like the neighbors complaining to the county about the road, it helps to let the relevant team know about the issue. Feedback like this is invaluable for the Windows team (that's what the "Send Feedback" link is there for after all). Even if the team decides not to fix a particular bug in this release it doesn't mean that it won't be fixed in the next release.

Engineering 7: A view from the bottom

LarryOsterman — Thu, 16 Oct 2008 17:43:26 GMT

About 2 months ago, Steven Sinofsky and Jon DeVaan started the “Engineering Windows 7” blog. The instant I saw the blog, I wanted to contribute to the blog (because I love writing :)).

I spent a fair amount of time thinking about what to write about and realized that one thing that wasn’t likely to be discussed was how the actual software engineering process of Windows 7 worked – not the data behind particular features, but how the hard core engineering work was managed. So I wrote it and submitted it to Steven and Jon.

My article (it’s too long to be considered a “post”) went live on the Engineering 7 blog sometime last night.

Enjoy!

Resilience is NOT necessarily a good thing

LarryOsterman — Thu, 01 May 2008 19:14:00 GMT

I just ran into this post by Eric Brechner who is the director of Microsoft's Engineering Excellence center.

What really caught my eye was his opening paragraph:

I heard a remark the other day that seemed stupid on the surface, but when I really thought about it I realized it was completely idiotic and irresponsible. The remark was that it's better to crash and let Watson report the error than it is to catch the exception and try to correct it.

Wow. I'm not going to mince words: What a profoundly stupid assertion to make. Of course it's better to crash and let the OS handle the exception than to try to continue after an exception.

I have a HUGE issue with the concept that an application should catch exceptions[1] and attempt to correct them. In my experience handling exceptions and attempting to continue is a recipe for disaster. At best, it takes an easily debuggable problem into one that takes hours of debugging to resolve. At it's worst, exception handling can either introduce security holes or render security mitigations irrelevant.

I have absolutely no problems with fail fast (which is what Eric suggests with his "Restart" option). I think that restarting a process after the process crashes is a great idea (as long as you have a way to prevent crashes from spiraling out of control). In Windows Vista, Microsoft built this functionality directly into the OS with the Restart Manager, if your application calls the RegisterApplicationRestart API, the OS will offer to restart your application if it crashes or is non responsive. This concept also shows up in the service restart options in the ChangeServiceConfig2 API (if a service crashes, the OS will restart it if you've configured the OS to restart it).

I also agree with Eric's comment that asserts that cause crashes have no business living in production code, and I have no problems with asserts logging a failure and continuing (assuming that there's someone who is going to actually look at the log and can understand the contents of the log, otherwise the logs just consume disk space).

But I simply can't wrap my head around the idea that it's ok to catch exceptions and continue to run. Back in the days of Windows 3.1 it might have been a good idea, but after the security fiascos of the early 2000s, any thoughts that you could continue to run after an exception has been thrown should have been removed forever.

The bottom line is that when an exception is thrown, your program is in an unknown state. Attempting to continue in that unknown state is pointless and potentially extremely dangerous - you literally have no idea what's going on in your program. Your best bet is to let the OS exception handler dump core and hopefully your customers will submit those crash dumps to you so you can post-mortem debug the problem. Any other attempt at continuing is a recipe for disaster.

-------

[1] To be clear: I'm not necessarily talking about C++ exceptions here, just structured exceptions. For some C++ and C# exceptions, it's ok to catch the exception and continue, assuming that you understand the root cause of the exception. But if you don't know the exact cause of the exception you should never proceed. For instance, if your binary tree class throws a "Tree Corrupt" exception, you really shouldn't continue to run, but if opening a file throws a "file not found" exception, it's likely to be ok. For structured exceptions, I know of NO circumstance under which it is appropriate to continue running.

Edit: Cleaned up wording in the footnote.

When you're analyzing the strength of a password, make sure you know what's done with it.

LarryOsterman — Tue, 13 Nov 2007 04:47:35 GMT

Every once in a while, I hear someone making comments about the strength of things like long passwords.

For example, if you have a 255 character password that just uses the 26 roman upper and lower case letters, plus the numeric digits. That means that your password has 62^255 possible values, if you can try a million million passwords per second, the time required would exceed the heat death of the universe.

Wow, that's cool - it means that you can never break my password if I use a long enough password.

Except...

The odds are very good that something in the system's going to take your password and apply a one-way hash to that password - after all, it wouldn't do to keep that password lying around in clear text where an attacker could see it. But the instant you take a hash of a secret, the strength of the secret degrades to the strength of the hash.

It's another example of the pigeonhole principle in practice - if you put N+M items into N slots, you're going to have some slots with more than one entry. The pigeonhole principle applies in this case as well.

In other words, if the password database that holds your password uses a hash algorithm like SHA-1, your 62^255 possible character password just got reduced in strength to a 256^20 possible value hash[1]. That means that any analysis that you've done on your password doesn't matter, because all an attacker needs to do is to find a different password that hashes to the same value as your password and they've broken your password. Since your password strength exceeds the strength of the hash code, you know that there MUST be a collision with a weaker password.

The bottom line is that when you're calculating the strength of a password, it's important that you understand what your password looks like to an attacker. If your password is saved as an SHA-1 or MD5 hash, that's the true maximum strength of your password.

[1]To be fair, 256^20 is something like 1.4E48, so even if you could still try a million million passwords per second, you're still looking at something like a million million years to brute force that database, but 256^20 is still far less than 62^255.

Some final thoughts on Threat Modeling...

LarryOsterman — Mon, 01 Oct 2007 19:54:00 GMT

I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah, I know I should have done this last week, but I got distracted :).

First, a summary of the threat modeling posts:

Part 1: Threat Modeling, Once again. In which our narrator introduces the idea of a threat model diagram

Part 2: Threat Modeling Again. Drawing the Diagram. In which our narrator introduces the diagram for the PlaySound API

Part 3: Threat Modeling Again, Stride. Introducing the various STRIDE categories.

Part 4: Threat Modeling Again, Stride Mitigations. Discussing various mitigations for the STRIDE categories.

Part 5: Threat Modeling Again, What does STRIDE have to do with threat modeling? The relationship between STRIDE and diagram elements.

Part 6: Threat Modeling Again, STRIDE per Element. In which the concept of STRIDE/Element is discussed.

Part 7: Threat Modeling Again, Threat Modeling PlaySound. Which enumerates the threats against the PlaySound API.

Part 8: Threat Modeling Again, Analyzing the threats to PlaySound. In which the threat modeling analysis work against the threats to PlaySound is performed.

Part 9: Threat Modeling Again, Pulling the threat model together. Which describes the narrative structure of a threat model.

Part 10: Threat Modeling Again, Presenting the PlaySound threat model. Which doesn't need a pithy summary, because the title describes what it is.

Part 11: Threat Modeling Again, Threat Modeling in Practice. Presenting the threat model diagrams for a real-world security problem .[1]

Part 12: Threat Modeling Again, Threat Modeling and the firefoxurl issue. Analyzing the real-world problem from the standpoint of threat modeling.

Part 13: Threat Modeling Again, Threat Modeling Rules of Thumb. A document with some useful rules of thumb to consider when threat modeling.

Remember that threat modeling is an analysis tool. You threat model to identify threats to your component, which then lets you know where you need to concentrate your resources. Maybe you need to encrypt a particular data channel to protect it from snooping. Maybe you need to change the ACLs on a data store to ensure that an attacker can't modify the contents of the store. Maybe you just need to carefully validate the contents of the store before you read it. The threat modeling process tells you where to look and gives you suggestions about what to look for, but it doesn't solve the problem. It might be that the only thing that comes out from your threat modeling process is a document that says "We don't care about any of the threats to this component". That's ok, at a minimum, it means that you considered the threats and decided that they were acceptable.

The threat modeling process is also a living process. I'm 100% certain that 2 years from now, we're going to be doing threat modeling differently from the way that we do it today. Experience has shown that every time we apply threat modeling to a product, we realize new things about the process of performing threat modeling, and find new, more efficient ways of going about the process. Even now, the various teams involved with threat modeling in my division have proposed new changes the process based on the experiences of our current round of threat modeling. Some of them will be adopted as best practices across Microsoft, some of them will be dropped on the floor.

What I've described over these posts is the process of threat modeling as it's done today in the Windows division at Microsoft. Other divisions use threat modeling differently - the threat landscape for Windows is different from the threat landscape for SQL Server and Exchange, which is different from the threat landscape for the various Live products, and it's entirely different for our internal IT processes. All of these groups use threat modeling, and they use the core mechanisms in similar ways, but because each group that does threat modeling has different threats and different risks, the process plays out differently for each team.

If your team decides to adopt threat modeling, you need to consider how it applies to your components and adopt the process accordingly. Threat Modeling is absolutely not a one-size-fits-all process, but it IS an invaluable tool.

EDIT TO ADD: Adam Shostak on the Threat Modeling Team at Microsoft pointed out that the threat modeling team has a developer position open. You can find more information about the position by going to here: http://members.microsoft.com/careers/search/default.aspx and searching for job #207443.

[1] Someone posting a comment on Bruce Schneier's blog took me for task for using a browser vulnerability. I chose that particular vulnerability because it was the first that came to mind. I could have just as easily picked the DMG loading logic in OSX or the .ANI file code in Windows for examples (actually the DMG file issues are in several ways far more interesting than the firefoxurl issue - the .ANI file issue is actually relatively boring from a threat modeling standpoint).

What's wrong with this code, part 21 - A Psychic Debugging Example - The answers.

LarryOsterman — Wed, 26 Sep 2007 23:17:31 GMT

So for the past couple of posts, I've been walking through a psychic debugging experience I had over the weekend.

As I presented the problem, there were three pieces of information needed to debug the problem.

An interface:

  class IPsychicInterface 
{
public:
    virtual bool DoSomeOperation(int argc, _TCHAR *argv[]) = 0;
};

A test application:

int _tmain(int argc, _TCHAR* argv[]) { register int value1 = 1; IPsychicInterface *psychicInterface = GetPsychicInterface(); register int value2 = 2;

      psychicInterface->DoSomeOperation(argc, argv);
    assert(value1 == 1);
    assert(value2 == 2);
    return 0;
}

and some assembly language code:

0040106B pop edi 0040106C pop ebx 0040106D mov al,1 0040106F pop esi 00401070 ret 0Ch

As I mentioned in my last post, the problem was tracked down to a stack imbalance when calling the DoSomeOperation method, and when I saw the postamble for DoSomeOperation, I quickly realized the answer to the problem.

There are essentially 4 separate calling conventions supported by Microsoft's compilers - it turns out that you can figure out several of them from just looking at the code. For the stdcall and thiscall calling conventions, input parameters are passed onto the routine, and the callee is responsible for cleaning up the stack (this contrasts with the cdecl calling convention where the caller is responsible for cleaning the stack). From the postamble, we know that this function is either a stdcall or a thiscall function, since the "ret" instruction adjusts the stack.

I've already stated that this is x86 code, and the RET 0CH indicates that the routine pops off 12 bytes of values off the stack. This is clearly a problem, because the DoSomeOperation routine only takes two parameters (which would take 8 bytes). The RET 0CH implies that the implementation of DoSomeOperation took 3 parameters!

This implies that we're dealing with a violation of the one definition rule (ODR). The One Definition Rule is a part of the C++ standard (section 3.2) which states: "No translation unit shall contain more than one definition of any variable, function, class type, enumeration type or template.". In other words, when you declare a function in separate object files, you need to make sure that they all use the same definitions of structures.

Most commonly ODR violations this show up when you change a header file but don't rebuild all the source files that depend on that file - there's a ton of work that's been done to automatically manage dependencies to avoid this particular issue.

And if you look at the source code for the PsychicInterface logic, you'll see the problem immediately:

class IPsychicInterface { public: virtual bool DoSomeOperation(int argc, _TCHAR *argv[], _TCHAR *envp[]) = 0; }; bool CPsychicInterface::DoSomeOperation(int argc, _TCHAR *argv[], _TCHAR *envp[]) { int count = argc; while (count--) { printf("%S", argv[count]); } return true; }

The PsychicInterface code has it's own private definition of IPsychicInterface which doesn't match the definition in the test application.

Obviously this is an utterly contrived example. The real problem was much more complicated than this - the violation was in an export from a DLL, and involved external components, which made this more complicated. In many ways, it was similar to the problem that Raymond talked about here (except in this case, we're in a position to fix the code involved).

What's wrong with this code, Part 21 - A psychic debugging example: The missing piece

LarryOsterman — Tue, 25 Sep 2007 19:39:04 GMT

As I mentioned yesterday, one of the other developers in my group had hit a sticky problem, and he asked me for my opinion on what was going wrong.

There were 3 pieces of information that I needed to use to diagnose the problem, I gave you two of them yesterday:

The interface:

class IPsychicInterface { public: virtual bool DoSomeOperation(int argc, _TCHAR *argv[]) = 0; };

And the test application:

int _tmain(int argc, _TCHAR* argv[]) { register int value1 = 1; IPsychicInterface *psychicInterface = GetPsychicInterface(); register int value2 = 2;

      psychicInterface->DoSomeOperation(argc, argv);
    assert(value1 == 1);
    assert(value2 == 2);
    return 0;
}

Originally the problem was that the ESI register was being trashed. Since the C and C++ calling convention requires that the ESI register be preserved and the ESI register was trashed, that narrowed down the failure to three possible causes to the problem:

Somewhere inside DoSomeOperation, there was a stack overflow that caused the saved version of ESI to be corrupted. This was actually my first thought.
Somewhere inside DoSomeOperation, there was a stack imbalance, which would cause garbage to be restored when the ESI register was popped off the stack. Normally the compiler catches these errors, so I originally discounted this possibility.
There was a horrible compiler bug or OS bug which caused the register to be trashed (which is extraordinarily unlikely (but has happened)).

The other developer had chased the problem down further and realized that there was a stack imbalance on the call to DoSomeOperation. There are basically two things that can cause a stack imbalance, most of the people who left comments in the original post caught one of them, some caught the other:

A calling convention mismatch.
A parameter declaration mismatch.

But I didn't have enough information to figure out which of the two it was. That's when he gave me the final piece that let me accurately figure out what was going wrong.

The final piece was the last bit of assembly language in the DoSomeOperation function:

  0040106B  pop         edi  
0040106C  pop         ebx  
0040106D  mov         al,1 
0040106F  pop         esi  
00401070  ret         0Ch

Now that you have the last piece, what was the bug? Be specific - we already know that the problem is a stack imbalance, but what's the root cause?

For a bonus, why didn't the compiler catch it?

Threat Modeling Again, Threat Modeling Rules of Thumb

LarryOsterman — Fri, 21 Sep 2007 20:20:35 GMT

I wrote this piece up for our group as we entered the most recent round of threat models. I've cleaned it up a bit (removing some Microsoft-specific stuff), and there's stuff that's been talked about before, but the rest of the document is pretty relevant.

---------------------------------------

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.

When we’re threat modeling, we should ensure that we’ve identified as many of the potential threats as possible (even if you think they’re trivial). At a minimum, the threats we list that we chose to ignore will remain in the document to provide guidance for the future.

Remember that the feature team can always decide that we’re ok with accepting the risk of a particular threat (subject to the SDL security review process). But we want to make sure that we mitigate the right issues.

To help you guide your thinking about what kinds of threats deserve mitigation, here are some rules of thumb that you can use while performing your threat modeling.

1. If the data hasn’t crossed a trust boundary, you don’t really care about it.

2. If the threat requires that the attacker is ALREADY running code on the client at your privilege level, you don’t really care about it.

3. If your code runs with any elevated privileges (even if your code runs in a restricted svchost instance) you need to be concerned.

4. If your code invalidates assumptions made by other entities, you need to be concerned.

5. If your code listens on the network, you need to be concerned.

6. If your code retrieves information from the internet, you need to be concerned.

7. If your code deals with data that came from a file, you need to be concerned (these last two are the inverses of rule #1).

8. If your code is marked as safe for scripting or safe for initialization, you need to be REALLY concerned.

Let’s take each of these in turn, because there are some subtle distinctions that need to be called out.

If the data hasn’t crossed a trust boundary, you don’t really care about it.

For example, consider the case where a hostile application passes bogus parameters into our API. In that case, the hostile application lives within the same trust boundary as the application, so you can simply certify the threat. The same thing applies to window messages that you receive. In general, it’s not useful to enumerate threats within a trust boundary. [Editors Note: Yesterday, David LeBlanc wrote an article about this very issue - I 100% agree with what he says there.]

But there’s a caveat (of course there’s a caveat, there’s ALWAYS a caveat). Just because your threat model diagram doesn't have a trust boundary on it, it doesn't mean that the data being validated hasn't crossed a trust boundary on the way to your code.

Consider the case of an application that takes a file name from the network and passes that filename into your API. And further consider the case where your API has an input validation bug that causes a buffer overflow. In that case, it’s YOUR responsibility to fix the buffer overflow – an attacker can use the innocent application to exploit your code. Before you dismiss this issue as being unlikely, consider CVE-2007-3670. The Firefox web browser allows the user to execute scripts passed in on the command line, and registered a URI handler named “firefoxurl” with the OS with the start action being “firefox.exe %1” (this is a simplification). The attacker simply included a “firefoxurl:<javascript>” in a URL and was able to successfully take ownership of the client machine. In this case, the firefox browser assumed that there was no trust boundary between firefox.exe and the invoker, but it didn’t realize that it introduced such a trust boundary when it created the “firefoxurl” URI handler.

If the threat requires that the attacker is ALREADY running code on the client at your privilege level, you don’t really care about it.

For example, consider the case where a hostile application writes values into a registry key that’s read by your component. Writing those keys requires that there be some application currently running code on the client, which requires that the bad guy first be able to get code to run on the client box.

While the threats associated with this are real, it’s not that big a problem and you can probably state that you aren’t concerned by those threats because they require that the bad guy run code on the box (see Immutable Law #1: “If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore”).

Please note that this item has a HUGE caveat: it ONLY applies if the attacker’s code is running at the same privilege level as your code. If that’s not the case, you have the next rule of thumb:

If your code runs with any elevated privileges, you need to be concerned.

We DO care about threats that cross privilege boundaries. That means that any data communication between an application and a service (which could be an RPC, it could be a registry value, it could be a shared memory region) must be included in the threat model.

Even if you’re running in a low privilege service account, you still may be attacked – one of the privileges that all services get is the SE_IMPERSONATE_NAME privilege. This is actually one of the more dangerous privileges on the system because it can allow a patient attacker to take over the entire box. Ken “Skywing” Johnson wrote about this in a couple of posts on his blog (1 and 2) on his excellent blog Nynaeve. David LeBlanc has a subtly different take on this issue (see here), but the reality is that both David and Ken agree more than they disagree on this issue. If your code runs as a service, you MUST assume that you’re running with elevated privileges. This applies to all data read – rule #2 (requiring an attacker to run code) does not apply when you cross privilege levels, because the attacker could be writing code under a low privilege account to enable an elevation of privilege attack.

In addition, if your component has a use scenario that involves running the component elevated, you also need to consider that in your threat modeling.

If your code invalidates assumptions made by other entities, you need to be concerned

The reason that the firefoxurl problem listed above was such a big deal was that the firefoxurl handler invalidated some of the assumptions made by the other components of Firefox. When the Firefox team threat modeled firefox, they made the assumption that Firefox would only be invoked in the context of the user. As such it was totally reasonable to add support for executing scripts passed in on the command line (see rule of thumb #1). However, when they threat modeled the firefoxurl: URI handler implementation, they didn’t consider that they had now introduced a trust boundary between the invoker of Firefox and the Firefox executable.

So you need to be aware of the assumptions of all of your related components and ensure that you’re not changing those assumptions. If you are, you need to ensure that your change doesn’t introduce issues.

If your code retrieves information from the internet, you need to be concerned

The internet is a totally untrusted resource (no duh). But this has profound consequences when threat modeling. All data received from the Internet MUST be treated as totally untrusted and must be subject to strict validation.

If your code deals with data that came from a file, then you need to be concerned.

In the previous section, I talked about data received over the internet. Microsoft has issued several bulletins this year that required an attacker tricking a user into downloading a specially crafted file over the internet; as a consequence, ANY file data must be treated as potentially malicious. For example, MS07-047 (a vulnerability in WMP) required that the attacker force the user to view a specially crafted WMP skin. The consequence of this is that that ANY file parsed by our code MUST be treated as coming from a lower level of trust.

Every single file parser MUST treat its input as totally untrusted –MS07-047 is only one example of an MSRC vulnerability, there have been others. Any code that reads data from a file MUST validate the contents. It also means that we need to work to ensure that we have fuzzing in place to validate our mitigations.

And the problem goes beyond file parsers directly. Any data that can possibly be read from a file cannot be trusted. <A senior developer in our division> brings up the example of a codec as a perfect example. The file parser parses the container and determines that the container isn't corrupted. It then extracts the format information and finds the appropriate codec for that format. The parser then loads the codec and hands the format information and file data to the codec.

The only thing that the codec knows is that the format information that’s been passed in is valid. That’s it. Beyond the fact that the format information is of an appropriate size and has a verifiable type, the codec can make no assumptions about the contents of the format information, and it can make no assumptions about the file data. Even though the codec doesn’t explicitly parse the file, it’s still dealing with untrusted data read from the file.

If your code is marked as “Safe For Scripting” or “Safe for Initialization”, you need to be REALLY concerned.

If your code is marked as “Safe For Scripting” (or if your code can be invoked from a control that is marked as Safe For Scripting), it means that your code can be executed in the context of a web browser, and that in turn means that the bad guys are going to go after your code. There have been way too many MSRC bulletins about issues with ActiveX controls.

Please note that some of the issues with ActiveX controls can be quite subtle. For instance, in MS02-032 we had to issue an MSRC fix because one of the APIs exposed by the WMP OCX returned a different error code if a path passed into the API was a file or if it was a directory – that constituted an Information Disclosure vulnerability and an attacker could use it to map out the contents of the users hard disk.

In conclusion

Vista raised the security bar for attackers significantly. As Vista adoption spreads, attackers will be forced to find new ways to exploit our code. That means that it’s more and more important to ensure that we do a good job ensuring that they have as few opportunities as possible to make life difficult for our customers. The threat modeling process helps us understand the risks associated with our features and understand where we need to look for potential issues.

Threat Modeling Again, Threat modeling and the fIrefoxurl issue.

LarryOsterman — Wed, 19 Sep 2007 20:33:30 GMT

Yesterday I presented my version of the diagrams for Firefox's command line handler and the IE/URLMON's URL handler. To refresh, here they are again:

Here's my version of Firefox's diagram:

And my version of IE/URLMON's URL handler diagram:

As I mentioned yesterday, even though there's a trust boundary between the user and Firefox, my interpretation of the original design for the Firefox command line parsing says that this is an acceptable risk[1], since there is nothing that the user can specify via the chrome engine that they can't do from the command line. In the threat model for the Firefox command line parsing, this assumption should be called out, since it's important.

Now let's think about what happens when you add in the firefoxurl URL handler to the mix?

For that, you need to go to the IE/URLMON diagram. There's a clear trust boundary between the web page and IE/URLMON. That trust boundary applies to all of the data passed in via the URL, and all of the data should be considered "tainted". If your URL handler is registered using the "shell" key, then IE passes the URL to the shell, which launches the program listed in the "command" verb replacing the %1 value in the command verb with the URL specified (see this for more info)[2]. If, on the other hand, you've registered an asynchronous protocol handler, then IE/URLMON will instantiate your COM object and will give you the ability to validate the incoming URL and to change how IE/URLMON treats the URL. Jesper discusses this in his post "Blocking the FIrefox".

The key thing to consider is that if you use the "shell" registration mechanism (which is significantly easier than using the asynchronous protocol handler mechanism), IE/URLMON is going to pass that tainted data to your application on the command line.

Since the firefoxurl URL handler used the "shell" registration mechanism, it means that the URL from the internet is going to be passed to Firefox's command line handler. But this violates the assumption that the Firefox command line handler made - they assume that their command line was authored with the same level of trust as the user invoking firefox. And that's a problem, because now you have a mechanism for any internet site to execute code on the browser client with the privileges of the user.

How would a complete threat model have shown that there was an issue? The Firefox command line threat model showed that there was a potential issue, and the threat analysis of that potential issue showed that the threat was an accepted risk.

When the firefoxurl feature was added, the threat model analysis of that feature should have looked similar to the IE/URLMON threat model I called out above - IE/URLMON took the URL from the internet, passed it through the shell and handed it to Firefox (URL Handler above).

So how would threat modeling have helped to find the bug?

There are two possible things that could have happened next. When the firefoxurl handler team[3] analyzed their threat model, they would have realized that they were passing high risk data (all data from the internet should be treated as untrusted) to the command line of the Firefox application. That should have immediately raised red flags because of the risk associated with the data.

At this point in their analysis, the foxurl handler team needed to confirm that their behavior was safe, which they could do either by asking someone on the Firefox command line handling team or by consulting the Firefox command line handling threat model (or both). At that point, they would have discovered the important assumption I mentioned above, and they would have realized that they had a problem that needed to be mitigated (the actual form of the mitigation doesn't matter - I believe that the Firefox command line handling team removed their assumption, but I honestly don't know (and it doesn't matter for the purposes of this discussion)).

As I mentioned in my previous post, I love this example because it dramatically shows how threat modeling can help solve real world security issues.

I don't believe that anything in my analysis above is contrived - the issues I called out above directly follow from the threat modeling process I've outlined in the earlier posts.

I've been involved in the threat modeling process here at Microsoft for quite some time now, and I've seen the threat model analysis process find this kind of issue again and again. The threat model either exposes areas where a team needs to be concerned about their inputs or it forces teams to ask questions about their assumptions, which in turn exposes potential issues like this one (or confirms that in fact there is no issue that needs to be mitigated).

Next: Threat Modeling Rules of thumb.

[1] Obviously, I'm not a contributor to Firefox and as such any and all of my comments about Firefox's design and architecture are at best informed guesses. I'd love it if someone who works on Firefox or has contributed to the security analysis of Firefox would correct any mistakes I'm making here.

[2] Apparently IE/URLMON doesn't URLEncode the string that it hands to the URL handler - I don't know why it does that (probably for compatibility reasons), but that isn't actually relevant to this discussion (especially since all versions of Firefox before 2.0.0.6, seem to have had the same behavior as IE). Even if IE had URL encoded the URL before handing it to the handler, Firefox is still being handed untrusted input which violates a critical assumption made by the Firefox command line handler developers.

[3] Btw, I'm using the term "team" loosely. It's entirely possible that the same one individual did both the Firefox command line handling work AND the firefoxurl protocol handler - it doesn't actually matter.

Threat Modeling Again, Threat Modeling in Practice

LarryOsterman — Wed, 19 Sep 2007 01:48:51 GMT

I've been writing a LOT about threat modeling recently but one of the things I haven't talked about is the practical value of the threat modeling process.

Here at Microsoft, we've totally drunk the threat modeling cool-aid. One of Adam Shostak's papers on threat modeling has the following quote from Michael Howard:

"If we had our hands tied behind our backs (we don't) and could do only one thing to improve software security... we would do threat modeling every day of the week."

I want to talk about a real-world example of a security problem where threat modeling would have hopefully avoided a potential problem.

I happen to love this problem, because it does a really good job of showing how the evolution of complicated systems can introduce unexpected security problems. The particular issue I'm talking about is known as CVE-2007-3670. I seriously recommend people go to the CVE site and read the references to the problem, they provide a excellent background on the problem.

CVE-2007-3670 describes a vulnerability in the Mozilla Firefox browser that uses Internet Explorer as an exploit vector. There's been a TON written about this particular issue (see the references on the CVE page for most of the discussion), I don't want to go into the pros and cons of whether or not this is an IE or a FireFox bug. I only want to discuss this particular issue from a threat modeling standpoint.

There are four components involved in this vulnerability, each with their own threat model:

The Firefox browser.
Internet Explorer.
The "firefoxurl:" URI registration.
The Windows Shell (explorer).

Each of the components in question play a part in the vulnerability. Let's take them in turn.

The Firefox browser provides a command line argument "-chrome" which allows you to load the chrome specified at a particular location.
Internet Explorer provides an extensibility mechanism which allows 3rd parties to register specific URI handlers.
The "firefoxurl:" URL registration, which uses the simplest form of URL handler registration which simply instructs the shell to execute "<firefoxpath>\firefox.exe -url "%1" -requestPending". Apparently this was added to Firefox to allow web site authors to force the user to use Firefox when viewing a link. I believe the "-url" switch (which isn't included in the list of firefox command line arguments above) instructs firefox to treat the contents of %1 as a URL.
The Windows Shell which passes on the command line to the firefox application.

I'm going to attempt to draw the relevant part of the diagrams for IE and Firefox. These are just my interpretations of what is happening, it's entirely possible that the dataflow is different in real life.

Firefox:

This diagram shows the flow of control from the user into Firefox (remember: I'm JUST diagramming a small part of the actual component diagram). One of the things that makes Firefox's chrome engine so attractive is that it's easy to modify the chrome because the Firefox chrome is simply javascript. Since the javascript being run runs with the same privileges as the current user, this isn't a big deal - there's no opportunity for elevation of privilege there. But there is one important thing to remember here: Firefox has a security assumption that the -chrome command switch is only provided by the user - because it executes javascript with full trust, it's effectively accepts executable code from the command line.

Internet Explorer:

This diagram describes my interpretation of how IE (actually urlmon.dll in this case) handles incoming URLs. It's just my interpretation, based on the information contained here (at a minimum, I suspect it's missing some trust boundaries). The web page hands IE a URL, IE looks the URL up in the registry and retrieves a URL handler. Depending on how the URL handler was registered, IE either invokes the shell on the path portion of the URL, or, if the URL handler was registered as an async protocol hander, it hands the URL to the async protocol handler.

I'm not going to do a diagram for the firefoxurl handler or the shell, since they're either not interesting or are covered in the diagram above - in the firefoxurl handler case, the firefoxurl handler is registered as being handled by the shell. In that case, Internet Explorer will pass the URL into the shell, which will happily pass it onto the URL handler (which, in this case is FireFox).

That's a lot of text and pictures, tomorrow I'll discuss what I think went wrong and how using threat modeling could have avoided the issue. I also want to look at BOTH of the threat models and see what they indicate.

Obviously, the contents of this post are my own opinion and in no way reflect the opinions of Microsoft.

Threat Modeling Again, Presenting the PlaySound Threat Model

LarryOsterman — Mon, 17 Sep 2007 19:30:45 GMT

It's been a long path, but we're finally at the point where I can finally present the threat model for PlaySound. None of the information in this post is new, all the information is pulled from previous posts.

----------------

PlaySound Threat Model

The PlaySound API is a high level multimedia API intended to render system sounds ("dings"). It has three major modes of operation:

It can play the contents of a .WAV file passed in as a parameter to the API.
It can play the contents of a Win32 resource or other memory location passed in as a parameter to the API.
It can play the contents of a .WAV file referenced by an alias. If this mode is chosen, it reads the filename from the registry under HKCU\AppEvents.

For more information on the PlaySound API and its options, see: The MSDN documentation for PlaySound.

PlaySound Diagram

The PlaySound API's data flow can be represented as follows.

PlaySound Elements

Application: External Interactor - The application which calls the PlaySound API.
PlaySound: Process - The code that represents the PlaySound API
WAV file: Data Store - The WAV file to be played, on disk or in memory
HKCU Sound Aliases: Data Store - The Windows Registry under HKCU\AppEvents which maps from aliases to WAV filenames
Audio Playback APIs: External Interactor - The audio playback APIs used for PlaySound. This could be MediaFoundation, waveOutXxxx, DirectShow, or any other audio rendering system.
PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary) - The data transmitted in this data flow represents the filename to play, the alias to look up or the resource ID in the current executable to play.
WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - The data transmitted in this data flow represents the WAVEFORMATEX structure contained in the WAV file being played.
WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - The data transmitted in this data flow represents the actual audio samples contained in the WAV file being played.
WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - The data transmitted in this data flow represents the contents of the HKCU\AppEvents\Schemes\.Default\<sound>\.Current[1]
WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - The data transmitted in this data flow represents both the WAVEFORMATEX structure read from the WAV file and the audio samples read from the file.

PlaySound Threat Analysis

Data Flows

WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Tampering
WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Information Disclosure
WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Denial of Service

Because all the Data flows are all within a single process boundary, there are no meaningful threats to those dataflows - the Win32 process model protects against those threats.

External Interactors

Application: External Interactor - Spoofing

It doesn't matter which application called the PlaySound API, so we don't care about spoofing threats to the application calling PlaySound.

Application: External Interactor - Repudiation

There are no requirements that the PlaySound API protect against Repudiation attacks.

Audio Playback APIs: External Interactor - Spoofing

The system default APIs are protected by Windows Resource Protection so they cannot be replaced. If an attacker does successfully inject his logic (by overriding the COM registration for the audio APIs or by some other means, the attacker is running at the same privilege level as the user, so can do nothing that the user can't do.

Audio Playback APIs: External Interactor - Repudiation

There are no requirements that the PlaySound API protect against Repudiation attacks.

Data Stores

Since the data stores involved in the PlaySound API are under the control of the user, we must protect against threats to those data stores.

WAV file: Data Store - Tampering

An attacker can modify the contents of the WAV file data store. To mitigate this attack, we will validate the WAVE header information; we're not going to check the actual WAV data, since it's just raw audio samples. Bug #XXXX filed to validate this mitigation.

WAV file: Data Store - Information Disclosure

The WAV file is protected by NT's filesystem ACLs which prevent unauthorized users from reading the contents of the file.

WAV file: Data Store - Repudiation

Repudiation threats don't apply to this store.

WAV file: Data Store - Denial of Service

The PlaySound API will check for errors when reading from the store and will return an error indication to its caller (if possible). When PlaySound is running in the "resource or memory location" mode and the SND_ASYNC flag is specified, the caller may unmap the virtual memory associated with the WAV file. In that case, the PlaySound may access violate while rendering the contents of the file[2]. Bug #XXXX filed to validate this mitigation.

HKCU Sound Aliases: Data Store - Tampering

An attacker can modify the contents of the sound aliases registry key. To mitigate this attack, we will validate the contents of the key. Bug #XXXX filed to validate this mitigation.

HKCU Sound Aliases: Data Store - Information Disclosure

The aliases key is protected by the registry ACLs which prevent unauthorized users from reading the contents of the key.

HKCU Sound Aliases: Data Store - Repudiation

Repudiation threats don't apply to this store.

HKCU Sound Aliases: Data Store - Denial of service

The PlaySound API will check for errors when reading from the store and will return an error indication to its caller (if possible).Bug #XXXX filed to validate this mitigation.

Processes

PlaySound: Process - Spoofing

Since PlaySound is the component we're threat modeling, spoofing threats don't apply.

PlaySound: Process - Tampering

The only tampering that can happen to the PlaySound process directly involves modifying the PlaySound binary on disk, if the user has the rights to do that, we can't stop them. For PlaySound, the file is protected by Windows Resource Protection, which should protect the file from tampering.

PlaySound: Process - Repudiation

We don't care about repudiation threats to the PlaySound API.

PlaySound: Process - Information Disclosure

The NT process model prevents any unauthorized entity from reading the process memory associated with the Win32 process playing Audio, so this threat is out of scope for this component.

PlaySound: Process - Denial of Service

Again, the NT process model prevents unauthorized entities from crashing or interfering with the process, so this threat is out of scope for this component.

PlaySound: Process - Elevation of Privilege

The PlaySound API runs at the same privilege level as the application calling PlaySound, so it is not subject to EoP threats.

PlaySound: Process - "PlaySound Command" crosses trust boundary: Elevation of Privilege/Denial of Service / Tampering

The data transmitted by the incoming "PlaySound Command" data flow comes from an untrusted source. Thus the PlaySound API will validate the data contained in that dataflow for "reasonableness" (mostly checking to ensure that the string passed in doesn't cause a buffer overflow). Bug #XXXX filed to validated this mitigation.

PlaySound: Process - "WAV file Data" data flow crosses trust boundary: Information Disclosure

It's possible that the contents of the WAV file might be private, so if some attacker can somehow "snoop" the contents of the data they might be able to learn information they shouldn't. Another way that this "I" attack shows up is described in CVE-2007-0675 and here. So how do we mitigate that threat (and the corresponding threat associated with someone spoofing the audio APIs)?

The risk associated with CVE-2007-0675 is out-of-scope for this component (if the threat is to be mitigated, it's more appropriate to handle that either in the speech recognition engine or the audio stack), so the only risk is that we might be handing the audio stack data that can be misused.

Since the entire APIs purpose is to play the contents of the WAVE file, this particular threat is considered to be an acceptable risk.

---

[1] The actual path is slightly more complicated because of SND_APPLICATION flag, but that doesn't materially change the threat model.

[2] The DOS issues associated with this behavior are accepted risks.

--------------

Next: Let's look at a slightly more interesting case where threat modeling exposes an issue.

Threat Modeling Again, Pulling the threat model together

LarryOsterman — Fri, 14 Sep 2007 17:58:34 GMT

So I've been writing a LOT of posts about the threat modeling process and how one goes about doing the threat model analysis for a component.

The one thing I've not talked about is what a threat model actually is.

A threat model is a specification, just like your functional specification (a Program Management spec that defines the functional requirements of your component), your design specification (a development spec that defines the architecture that is required to implement the functional specification), and your test plan (a test spec that defines how you plan on ensuring that the design as implemented meets the requirements of the functional specification).

Just like the functional, design and test specs, a threat model is a living document - as you change the design, you need to go back and update your threat model to see if any new threats have arisen since you started.

So what goes into the threat model document?

Obviously you need the diagram and an enumeration and description of the elements in your diagram.
You also need to include your threat analysis, since that's the core of the threat model.
For each mitigated threat that you call out in the threat analysis, you should include the bug # associated with the mitigation
You should probably have a one or two paragraph description of your component and what it does (it helps an outsider to understand your diagram), similarly, having a list of contacts for questions, etc are also quite useful.

The third item I called out there reflects an important point about threat modeling that's often lost.

Every time your threat model indicates that you have a need to mitigate a particular threat, you need to file at least one bug and potentially two. The first bug goes to the developer to ensure that the developer implements the mitigation called out in the threat model, and the second bug goes to a tester to ensure that the tester either (a) writes tests to verify the mitigation or (b) runs existing tests to ensure that the mitigation is in place.

This last bit is really important. If you're not going to follow through on the process and ensure that the threats that you identified are mitigated, then your just wasting your time doing the threat model - except as an intellectual exercise, it won't actually help you improve the security of your product.

Next: Presenting the PlaySound threat model!