Mitigating Software Vulnerabilities
Matt Miller, Tim Burrell, and Michael Howard from the Microsoft Security Engineering Center published a paper last week on Mitigating Software vulnerabilities. In a nutshell, they advocate a set of tactics that limit – or outright block – known and emerging attack techniques. Rather than play catch-up and patch the threat du jour, they outline use cases for the technologies that Microsoft employs within their own products to make it much harder to compromise code with canned attacks. Over the past decade, Microsoft has developed a variety of exploit mitigation technologies that are designed to make it more difficult for attackers to exploit software vulnerabilities such as buffer overruns. This section enumerates each of the mitigation technologies currently available, and provides answers for common questions that relate to how each technology works, how effective they are, and any important performance or compatibility considerations. Three basic recommended tactics are: Generic detection of a hacker’s attempt to subvert a system though exception handler overwrites or running code from within data segments. Randomizing code or configurations to breaks canned attacks Employ simple security ‘speed bumps’ that require a little bit of insider knowledge which is difficult for an attacker to acquire. Two things I like about the paper: First, the tactics approach exploitation protection from a developer’s prospective. This is not a third-party tool or analyzer or bolt-on protection. These tools and complier options are in the context of the development environment, and offer protections a developer has some degree of control over. The more involved the developer is in the security precautions in (or for) their code, the more likely they are to think about how they can protect it. Second, this mindset assumes that code will be under attack and looks for ways to make it more difficult to subvert – rather than desperately hoping the newest mitigation can stop a determined attacker permanently. Understanding that small variations can cause huge headaches for attackers and malware developers is a fundamental insight for defensive development. While this paper is recommended reading for developers, bring a big cup of coffee. The documents are only about 10 pages, but the terminology is a bit obtuse. For example, “artificial diversity” and “knowledge deficits” are accurate but unfamiliar terms. I am pretty sure there is a better way to say “new invariants”. Still, esoteric vocabulary seems to be this paper’s main vice – slight criticism indeed. Educating developers on a simple set of tactics – built into their development tools – is powerful. The key insight is that you can take away the easy (known) pathways in and out of your code, and make it very expensive for an attacker to break your application. It is just as important to give yourself more time to detect iterative attacks in progress. The paper is well worth your time. Share:
