DLL exploit not a job for secure coding programs

The big "zero-day" exploit this week was the malicious Windows DLL payload brought to the spotlight by Rapid7's HD Moore. Two other researchers appear to have also found this bug as well. Microsoft released a security advisory on this class of vulnerabilities, and stated "This issue is caused by specific insecure programming practices that allow so-called "binary planting" or "DLL preloading attacks". These practices could allow an attacker to remotely execute arbitrary code in the context of the user running the vulnerable application when the user opens a file from an untrusted location."

So which one is it? Is this an issue caused by insecure coding practices, or by insecure desktop administration and security policy execution? The secure coding methodology made famous by Microsoft didn't protect them from having at least 4 major applications affected by this bug. Researchers say that Microsoft has known about this class of vulnerability for anywhere from 6 months to 10 years, depending on who you read. So why didn't they catch this bug? While it might seem to be, this is NOT an admonishment of Microsoft or their secure coding practices. The Microsoft SDL and SDL-Agile are successful, game-changing strategies that I give a lot of credit. The reason the SDL didn't catch this DLL code execution bug is because a bug like this is outside of the scope of a successful secure coding program. In a secure software development lifecycle, the goal is to prevent bugs from the start that are easy and cost-efficient to eliminate. The SDL is great at preventing SQL Injections and catching bugs where code sanitization is the fix, however this bug is in code that is behaving exactly as it was designed. In April 2009, Aviv Raff was told by Microsoft when dealing with a very similar disclosure that this bug was not a simple fix. "They said it would be very problematic to fix the whole thing, and would break a lot of third-party Windows applications."

Microsoft has put out a tool to help administrators mitigate the problem, and has a lengthy description to help guide developers to construct their code differently in the future. This is an appropriate response based on their Security Response Practices. It is possible that it is more cost-efficient to respond to a disclosure such as this than it is to prevent it. Third-party companies such as Rapid7 and Errata Security are adding modules to their auditing tools to check for this attack. Actions such as these may actually cause the DLL Preloading Attacks to become "low-hanging fruit" in the development process in the future, but for now it should not be expected that a secure coding program should have prevented this attack.