Share via

Threat Modeling Again, Analyzing the threats to PlaySound

  • Article

In my last post, I enumerated a bewildering array of threats that the PlaySound API is subject to, today I want to work through the analysis process for each of those threats.

To refresh, here's the DFD and the list of threats:

  1.  Application: External Interactor - Spoofing
  2.  Application: External Interactor - Repudiation
  3. PlaySound: Process - Spoofing
  4. PlaySound: Process - Tampering
  5. PlaySound: Process - Repudiation
  6. PlaySound: Process - Information Disclosure
  7. PlaySound: Process - Denial of Service
  8. PlaySound: Process - Elevation of Privilege
  9. WAV file: Data Store - Tampering
  10. WAV file: Data Store - Information Disclosure
  11. WAV file: Data Store - Repudiation
  12. WAV file: Data Store - Denial of Service
  13. HKCU Sound Aliases: Data Store - Tampering
  14. HKCU Sound Aliases: Data Store - Information Disclosure
  15. HKCU Sound Aliases: Data Store - Repudiation
  16. HKCU Sound Aliases: Data Store - Denial of service
  17. Audio Playback APIs: External Interactor - Spoofing
  18. Audio Playback APIs: External Interactor - Repudiation
  19. PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary) - Tampering
  20. PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary) - Information Disclosure
  21. PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary) - Denial of Service
  22. WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
  23. WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
  24. WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
  25. WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
  26. WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
  27. WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
  28. WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Tampering
  29. WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Information Disclosure
  30. WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary) - Denial of Service
  31. WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Tampering
  32. WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Information Disclosure
  33. WAV file Data (PlaySound -> Audio Playback APIs): DataFlow - Denial of Service

 

Let's start with the dataflows, mostly because there are so many of them.

For each of the dataflows (PlaySound Comand, WAVE Header, WAV file Data, WAV filename and WAV file Data), because the dataflows are all within a single process boundary, there are no meaningful threats to those dataflows.  So with one simple assertion, I've dealt with almost half the threats associated with PlaySound (this isn't strictly true - there ARE threat associated with the dataflows, I'll get to that details when I discuss the threats to the PlaySound process).

 

Next, let's look at the external interactors.

For the Application interactor, we don't care about spoofing threats - we don't care which application calls PlaySound, so once again, we can simply assert that Spoofing threats don't apply. We can make a similar assertion about the Repudiation threat - for PlaySound, there is no risk of the interactor repudiating their action (nobody's going to come along and claim that they didn't really make that noise).

For the audio playback APIs, things are a smidge more complicated.  Once again, repudiation isn't an issue, so that particular threat's taken care of.   Spoofing is a more interesting issue.  What happens if someone spoofs the audio engine?  At one level, this is a "if it looks like a duck, walks like a duck and quacks like a duck, it's a duck" type of problem - because the entity claiming to be the audio engine follows the contracts of the audio engine, do we really care if it's the real audio engine or not?  Maybe, maybe not.  For now, let's table this particular threat (I'll come back to it later).

 

Ok, we've mostly handled the interactors and data flows.  Let's discuss the two data stores.

Each of the two data stores are subject to Tampering, Repudiation, Information Disclosure and Denial of Service threats.

An attacker can tamper with the contents of both stores, and we need to have mitigations in place for that: The PlaySound API will validate the contents of the data read from either data store for "reasonableness".

There are a number of ways that Denial of Service attacks show up for files and registry keys - first off, the file/key requested might not be present.  Secondly, the file might be on a removable storage medium which is removed during the read (registry keys also suffer from this - if you are using roaming profiles, then the registry hives might be located over the network).  There are others, but I believe these two are the big ones.  For PlaySound, all we need to do is to check error returns when reading from the data stores.  There are no performance guarantees associated with PlaySound so the fact that it may take a long time to read the data doesn't constitute a threat.

So the analysis for the data stores is:

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. 

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

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.

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

 

That's everything, except for the actual PlaySound API.  I'm going to take each of the threats to PlaySound in turn:

 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.  For non Windows components, if you follow Microsoft's recommendations, the ACLs on the filesystem usually protect your component 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.

 

But that's not the complete set of threats associated with the PlaySound service, there are two more sets of threats that need to be mitigated.

The first is a threat that comes from the "PlaySound Command" data flow.  The data transmitted over that data flow comes from an untrusted source, and thus it represents a Tampering and Denial of Service threat.  Since the data conceivably comes from an anonymous source (it could come from a web page in some circumstances), it's also potentially subject to an EoP threat.

The mitigation to all three of these threats is the same:

PlaySound: Process - 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).

The last threat is an Information Disclosure threat associated with the "WAV file Data (PlaySound -> Audio Playback APIs): DataFlow" data flow.  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)?

First the spoofing issue against the audio APIs.  For that, I assert that it doesn't matter.  Here's the logic: There are two ways that the audio APIs can be spoofed.  The first is if the attacker somehow modifies or replaces the files that constitute the audio subsystem.  That threat is mitigated by the ACLs on those files - only administrators have the ability to modify those files, and you can't protect against an administrator.  The second way that the APIs can be spoofed is if someone overrides the COM registration for the audio stack that's located in HKLM - again, that can't be done because you have to be an administrator to modify those keys.  There IS a possible attack caused by modifying HKCU\Classes, but that threat isn't particularly relevant - it (a) requires that the user run a program to modify those registry keys and (b) doesn't give the user any abilities that they don't already have.

Finally, the information disclosure vulnerability associated with sending the audio data to the Playback 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.

 

Wow, that's a LOT of typing for such a small feature, it ended up being much more than I had anticipated.

 

Next: Pulling the threat model together.

Comments

  • Anonymous
    September 13, 2007
    The comment has been removed

  • Anonymous
    September 13, 2007
    That sounds about right. Actually I think the comments in your 4th paragraph are quite reasonable, I'll do my best to ensure that the final threat model contains this reasoning.

  • Anonymous
    September 14, 2007
    "for PlaySound, there is no risk of the interactor repudiating their action (nobody's going to come along and claim that they didn't really make that noise)." None immediately come to mind, but I'm willing to bet there are situations where that isn't always true.

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