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.
----------------
The PlaySound API is a high level multimedia API intended to render system sounds ("dings"). It has three major modes of operation:
For more information on the PlaySound API and its options, see: The MSDN documentation for PlaySound.
The PlaySound API's data flow can be represented as follows.
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.
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
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
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.
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.
<em>Let's look at a slightly more interesting case where threat modeling exposes an issue.</em>
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.
<p>
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.
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 <i>was</i> missed, the challenge is to determine what and why.
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.
Adam Shostack here. I said recently that I wanted to talk more about what I do. The core of what I do
I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,
"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
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.