Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Why is defense in depth so important?

Why is defense in depth so important?

  • Comments 16
Yesterday's post on the principal of least privilege engendered some discussion about how important the PLP was.

Many of the commentors (including Skywing, the originator of the discussion) felt that it wasn't important because malware could always enable the privilege.

And they're right - it just raises the bar.  But raising the bar is important.

The PLP is a specific example of a technique named "Defense in Depth" - the idea is that even if you don't know about a specific attack vector to your component, you still ensure that your code doesn't have defects.

Let me give a contrived but feasible example.

I've got an API that lives in a DLL, call it MyCoolNewImageRenderingAPI.dll.  The component ships as a part of Windows (or it's open source and freely redistributable, it doesn't really matter).

It turns out that there's a bug in my API - if you pass the API a filename that's invalid, it can overflow.

Do you fix the bug?  Your code lives in a DLL.  It's not network facing.  None of the components that use the DLL are network facing.  So it's not exploitable, right?

Well, it might not be exploitable, today.  But you still have to fix the bug.


Because you can't control the callers of your API.  You simply can't predict what they're going to do with the API.

What if the brand spanking new IceWeasel web browser decides that it really likes your API and decides to use it to render images.  And further, what if that browser allows a web site author to control the filename, or a portion of the filename passed into the API.

Now all an attacker needs to do is to construct a filename that exploits your buffer overflow and they own the client machine.  In the absence of your bug, the only  consequence of the browser's allowing the attacker to control the name might be a denial of service attack (it might crash the browser, or fail to render the page correctly).  But with your bug, your "unexploitable" bug just became a security hole.

You could argue back and forth about whether this is a bug in the browser or not, but ultimately it's not the browsers responsibility to work around YOUR bugs.  You just need to fix the bug.

And that, in a nutshell is what defense in depth is all about.  If you've got a problem in your code that might conceivably be used to to launch an exploit, even though you believe that there are ample mitigations in place, you still need to fix the problem.