Every crash is a potential security vulnerability


Whenever I post about a programming error that can lead to crashes, the security team gets all excited and starts looking for ways to exploit it. For example, when I wrote about the fundamentally flawed DONT_RESOLVE_DLL_REFERENCES flag, the security folks went scouring through the Windows source code looking for anybody who passed that flag, and then tried to come up with ways they could trick the code into loading an unintended DLL and causing trouble.

I wouldn't have known about this exercise at all if one of the team members hadn't forwarded me some email discussing their preliminary investigations as if to say, "See what you started?"

Comments (8)
  1. Anonymous says:

    I don’t know if it was highlighted in that thread or not, but DONT_RESOLVE_DLL_REFERENCES is the only way to inspect a DLL whose references may not be satisfied (so it’s useful for "what does DLL do?" tools, I have used it to inspect a mixed mode DLL through reflection).

  2. typo.pl says:

    I used to read all the email automatically sent to the NT checkin email alias when developers checked in code to find any interesting bug patterns for my typo.pl perl script.

    I depended on the checkin comment having sufficient information. Sadly most devs didn’t enter much interesting info.

    Two that I remember were the change to EnterCriticalSection behaviour – the API contract changed so that it could throw an exception – and one from yourself, "if (!x & 1)" is not the same as "if (!(x & 1))"

  3. Anonymous says:

    It’s also useful if you want to check through a directory for dlls implementing a certain set of procedures (e.g. plugins) but when you do not want to execute DllMain() of ‘random’ dlls that aren’t the ones you’re looking for.

    Anyway, I’m sorry Raymond… but isn’t it sort of interesting, I suppose in a masochistic sort of way, to see how one little comment can evolve into a fire-storm of emails behind your back?

  4. Anonymous says:

    Who’s full of themselves now, Raymond?  (c.f. your earlier post today)  People can be full of themselves in different ways.

  5. Anonymous says:

    "Who’s full of themselves now, Raymond?  (c.f. your earlier post today)  People can be full of themselves in different ways."

    Some people can feel proud of what they do Dino, nothing wrong with that.

    One question: What do you contribute?

  6. Anonymous says:

    I remember being on a security call where the customer wanted us to assure them that our desktop application could not reveal any information to a potential hacker. While we do make sure error dialogs, etc, reveal as little as possible, if they are on your *desktop* machine, then all they need is a little WinDBG and they can find all sorts of interesting information – especially for managed apps.

    It was actually good – after I brought that up, they said, "So I guess you can’t protect us from misconfiguration, viruses or trojan horses either, huh" and we had a good chuckle.

  7. Anonymous says:

    "For example, when I wrote about the fundamentally flawed DONT_RESOLVE_DLL_REFERENCES flag, the security folks went scouring through the Windows source code looking for anybody who passed that flag, and then tried to come up with ways they could trick the code into loading an unintended DLL and causing trouble."

    That despite the fact that if the code was tricked into loading an unintended DLL, DONT_RESOLVE_DLL_REFERENCES means that it is actually going to cause *less* trouble, because the DllMain is not executed, while without this flag, if the code was tricked into loading an unintended DLL, the DllMain code in the DLL will execute and can cause trouble.

  8. Anonymous says:

    @Yuhong

    As explained in the earlier post, even if the code loaded a common trusted dll (in fact especially if it did) with this flag, it would be setting a ticking time bomb for the next piece of code that loaded that dll and tried to call a function from it.

    So really you’re not tricking it by telling it which library to load (although as you note, loading an arbitrary dll is dangerous enough), only tricking it to get it to load anything with the aforementioned flag.

Comments are closed.