Share via

Threat Modeling Again, Threat Modeling PlaySound

  • Article

Finally it's time to think about threat modeling the PlaySound API.

Let's go back to the DFD that I included in my earlier post, since everything flows from the DFD.

 

This dataflow diagram contains a number of elements, they are:

  1. Application: External Interactor
  2. PlaySound: Process
  3. WAV file: Data Store
  4. HKCU Sound Aliases: Data Store
  5. Audio Playback APIs: External Interactor
  6. PlaySound Command (Application->PlaySound): DataFlow (Crosses Threat Boundary)
  7. WAVE Header (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary)
  8. WAV file Data (WAV file-> PlaySound) : DataFlow (Crosses Threat Boundary)
  9. WAV filename (HKCU Sound Aliases -> PlaySound) : DataFlow (Crosses Threat Boundary)
  10. WAV file Data (PlaySound -> Audio Playback APIs): DataFlow

Now that we've enumerated the elements, we apply the STRIDE/Element methodology, which allows us to enumerate the threats that this component faces:

  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

 Phew.  You mean that the PlaySound API can be attacked in 33 different ways?  That's unbelievable.

It's true.  There ARE 33 ways that you can attack the PlaySound API, however many of them are identical, and some of which are irrelevant.  That's the challenge of the next part of the process, which is the analysis phase.

As I mentioned in the first STRIDE-per-element post, STRIDE-per-element is a framework for analysis.  That's where common sense and your understanding of the system comes into focus.

And that's the next part in the series: Analyzing the threats enumerated by STRIDE-per-element.  This is the point at which all the previous articles come together.

Comments

  • Anonymous
    September 12, 2007
    Adam Shostack here. I've been meaning to talk more about what I actually do, which is help the teams

  • Anonymous
    September 12, 2007
    Hypothetical question here.  Suppose the design of the throttler were reversed, so that opening a network socket would impose a Denial of Service on PlaySound.  Would that be #7 in your list?  Do you have a way to distinguish intended threats from unintended threats?

  • Anonymous
    September 13, 2007
    The comment has been removed

  • Anonymous
    September 13, 2007
    In my last post , I enumerated a bewildering array of threats that the PlaySound API is subject to, today

  • Anonymous
    September 13, 2007
    My question >> Do you have a way to distinguish intended threats from >> unintended threats? meant in the design of the threat model, not in Microsoft's decision whether to issue a bulletin about it. On the other issue > There's a huge difference between a denial of service and a > reduction in service (IMHO). For PlaySound maybe it wouldn't often matter, though if we want to play an alarm warning that a hard drive is overheating then it would matter.  But in general I think it depends on how huge the difference is.  If a reduction in service means that a bank's web site can process 50% of customer payments that it was supposed to process, I think the difference between 50% and 100% is huger than the difference between 50% and 0%.

  • Anonymous
    September 13, 2007
    The comment has been removed

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