Threat Modeling Again, Presenting the PlaySound Threat Model

re: Threat Modeling Again, Presenting the PlaySound Threat Model

Larry Osterman [MSFT] — Tue, 02 Oct 2007 18:57:44 GMT

Thor, in the analysis for the WAV file data store, there's the following comment:

"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. "

I believe that this addresses your concern.

Note that an access violation in this case isn't considered a defect or a security hole (see my threat modeling rules of thumb - if the attack requires that the attacker run code in your process, it's not a big deal). It's possible that this could be used as one step in a multi-part compromise, but I'm willing to live with that risk.

Having said that, there IS a design issue that this exposes: there's no way of knowing when PlaySound is done with playing a sound if you specify the SND_ASYNC flag.

re: Threat Modeling Again, Presenting the PlaySound Threat Model

Thor Larholm — Tue, 02 Oct 2007 18:32:48 GMT

"It can play the contents of a Win32 resource or other memory location passed in as a parameter to the API."

I don't recall seeing this mode of operation mentioned in the earlier articles of this series. Where is its data flow in the diagram and its remediations? I would definitely want to ensure some level of correctness on this argument.

Cheers

Thor Larholm

Some final thoughts on Threat Modeling...

Larry Osterman's WebLog — Mon, 01 Oct 2007 19:54:26 GMT

I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,

The Trouble with Threat Modeling

The Security Development Lifecycle — Wed, 26 Sep 2007 22:27:53 GMT

Adam Shostack here. I said recently that I wanted to talk more about what I do. The core of what I do

re: Threat Modeling Again, Presenting the PlaySound Threat Model

Adam — Wed, 19 Sep 2007 18:27:42 GMT

Thanks. To be clear, my issue wasn't really the wording, it was the issue that you surfaced--a lot of the work feels like a waste.

re: Threat Modeling Again, Presenting the PlaySound Threat Model

Larry Osterman [MSFT] — Wed, 19 Sep 2007 07:31:29 GMT

Point taken. The wording was unquestionably awkwards.

And you're absolutely 100% right. We don't know what's going to be a problem - threat modeling helps us know where to look.

Of course, it leaves out the bigger question: did we do the modeling correctly? Did we actually check what we needed to check? What did we miss?

The firefoxurl in the next post is a great example of this: Something was missed, the challenge is to determine what and why.

re: Threat Modeling Again, Presenting the PlaySound Threat Model

Adam — Wed, 19 Sep 2007 07:13:01 GMT

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

I have to admit..I winced really hard when I read that. But then I thought about it, and I want to add to it.

What you've been doing here is walking through a lot of possibilities. Some of those turn out to be uninteresting, and we learn something. Others (as we've discussed) were pretty clearly uninteresting, and we need to evolve the process more.

Before you started, we didn't know how many of these would expose issues or not. Threat modeling has given us confidence that you've thought through these issues. And that's worth a lot.

In an ideal world, we'd help you find out which ones aren't relevant in less time.