Udostępnij za pośrednictwem

Threat Modeling Again, Presenting the PlaySound Threat Model

  • Artykuł

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

 

  1. Application: External Interactor - The application which calls the PlaySound API.
  2. PlaySound: Process - The code that represents the PlaySound API
  3. WAV file: Data Store - The WAV file to be played, on disk or in memory
  4. HKCU Sound Aliases: Data Store - The Windows Registry under HKCU\AppEvents which maps from aliases to WAV filenames
  5. Audio Playback APIs: External Interactor - The audio playback APIs used for PlaySound.  This could be MediaFoundation, waveOutXxxx, DirectShow, or any other audio rendering system.
  6. 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.
  7. 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.
  8. 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.
  9. 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]
  10. 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.

Comments

  • Anonymous
    September 18, 2007
    <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. <p> 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. <p> In an ideal world, we'd help you find out which ones aren't relevant in less time.

  • Anonymous
    September 18, 2007
    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.

  • Anonymous
    September 19, 2007
    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.  

  • Anonymous
    September 26, 2007
    Adam Shostack here. I said recently that I wanted to talk more about what I do. The core of what I do

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

  • Anonymous
    October 02, 2007
    "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

  • Anonymous
    October 02, 2007
    The comment has been removed