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.

Why?

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.

  • According to Raymond Chen it is Windows' responsibility to work around third party software bugs. So the same would apply here, the IceWeasel browser should work around your bugs ;)
  • Now this brings up another question, for me anyway. Sometime's I think 90% maybe 80% of the code I write is code to protect my apps, be it from the user entering in bad input, checking for bad input in my arguments in my code libraries and so on. I mean you have to protect inputs basically on every method, constructor, field, what ever. How much of this protection and validation code do you think we write as programmers? Rough guestimate how much of this do you think is in Windows.

    I mean when you think about it something like typing a URL into IE has to get validated several times. I have wondered how much time is spent reprocessing and checking valid input. Not that I see any way around it IE probably checks it in the UI, then it gets passed to the browser control to navigate method which it gets validated there I am sure since that is an open component all of us developers can use. Then it goes to some networking component, all the way to the network card and then on to the routers, end server and so on. My guess is that simple url string gets checked several hundred times along the way.
  • First of all, I agree that the bug needs to be fixed -- it is just bad code -- period. But, does the responsibility argument change if the API is undocumented? Not badly-documented, but used by someone who has "figured out" the interface without the benefit of any documentation?
  • Jerry, it's not Windows responsibility to work around bugs.

    It's Windows responsibility to ensure that the broadest set of programs continues to run on the platform.

    I don't know if IceWeasel has the same responsibility (especially since I made up IceWeasel in my head as I was writing the post). Maybe it does. Maybe it will workaround the security bug in MyCooLnewImageRenderingAPI.dll. But maybe it won't.

    But more importantly, it wouldn't have had to if I had done my job right.
  • I seem to remember the "Hack PC Week" contest being won by someone exploiting a bug with the handling of a filename in an open library.
  • It's easy to say that malware will just increase a privilege, but in this day and age a lot of exploits are found by entering random strings and waiting for some buffer along the way to overflow. Hackers may have little idea which program or dll will actually fail, so they don't know which privelege to increase. If there's even the smallest speedbump, you increase the chance that they'll give up and move to something else. I presume a lot of work that went into Windows XP SP2 was on stuff like this.
  • Larry, I absolutely agree with the last sentence. That's why I posted my trollish comment, because covering up for other code's problems will not lead to people doing their job right. Breaking their code and explaining what they should have done will. But then, I'm a developer, not a marketing or PM type that needs to worry about market share or release dates :)
  • "According to Raymond Chen it is Windows' responsibility to work around third party software bugs. So the same would apply here, the IceWeasel browser should work around your bugs ;) "

    But why SHOULDN'T Windows play a role in defence in depth? If every layer adds its own security then you are a lot stronger compared to just passing it off to another piece of code.

    Let me give you an in context example... MyCoolNewImageRenderingAPI.dll uses the video APIs on the local machine to resize images but you discover that if you try and stretch an image too big you can cause the machine to reset...

    This might be a problem with the video card's drivers but defence in depth dictates that *EACH LEVEL* checks the input to avoid this kind of situation.

    Thus IceWeasel browser sets a hard limit of 9999 on image resize, MyCoolNewImageRenderingAPI.dll also sets an appropriate max limit and the video drivers fix the original issue.

    But that is a perfect fix, now imagine two years down the line, IceWeasel browser never set a hard limit and the video drivers haven't been repaired for some generic manufacturer's cards ... unaware of that fact the IceWeasel browser team release an update that uses their own rendering API which will "speed up rendering by 200%!" but when they did so they never took into account this problem that existed a couple of years ago (why should they? It isn't a problem NOW it has been fixed). Thus they have re-created the error scenario.

    If they had added appropriate checks on each layer it would have been very difficult to recreate.

    PS - The above is happening RIGHT NOW with internet explore, Microsoft refuses to fix it...
  • > The component ships as a part of Windows
    > (or it's open source and freely
    > redistributable, it doesn't really matter).

    In some ways it doesn't really matter but in some ways it sure does.

    If MyCoolNewImageRenderingAPI.dll is part of Internet Explorer then it remains an integral part of Windows even if the user sets preferences to use a different browser. MyCoolNewImageRenderingAPI.dll will still be needed for downloading of Windows Update security patches, and MyCoolNewImageRenderingAPI.dll will still be exploitable if there's any way for malware to invoke it.

    If MyCoolNewImageRenderingAPI.dll is freeware then people can refrain from installing it, or if they did install it then they can uninstall it and get their money back[*].

    [* Well if they paid more than 0 yen for it then they might not get their money back, but still, compare this to integral components of Windows.]
  • The term defense in depth raises interesting possibilities. In WW1 the german army devveloped the elastic defense. This was defense in depth and attackes were defeated in the depth of the defense. This contrasted to defending a line (where artilary would kill most of the defending soldiers).

    The few front line troops would hide and then attack the enemy flanks as they passed. The sucessive defenses would break the attacls cohesion and then there would be a counter attack and it would push the attackers back.

    So we could have things like the firewall shutting down if attacked (to protect itself) then starting up again.

    It's just a different conceptual model to what you mean by the phrase.
  • s/principal/principle
  • Friday, June 24, 2005 5:59 AM by speling terrarist

    > s/principal/principle

    Didn't they teach you anything at school? The most privileged party is the principal ^_^
  • Larry,

    I think your subconscience is helping you write this post. I've no idea where this was first mentioned, but I read about[1] the IceWeasel browser some time ago. :)

    [1] http://lwn.net/Articles/118268/
  • Ron, that's SO wierd. I absolutely had no idea about that.
  • speling terrarist is right - it should be principle of least privilege.
Page 1 of 2 (16 items) 12