Good…

Project Zero is a group of security folks at Google who are doing attack research, finding vulnerabilities, reporting them and blogging about them. They are both well-regarded (due to their skill) and controversial (due to their policy of announcing bugs on a set schedule, regardless of whether patches are available).

I like what Project Zero is doing. It is good to find security vulnerabilities and get them patched. It is also good to study and document how to exploit vulnerabilities, because vendors would like to pretend that these bugs are not going to harm anyone. I think that vendors historically have not fixed vulnerabilities promptly and this should be exposed.

… but not good enough

There is a big problem with Project Zero, however. Project Zero, like most of the attack research community, finds one bug at a time and closes one bug at a time.

This is a very poor strategy for making a difference, given that there are an infinite number of bugs in our software.

Moreover, Project Zero ignores the underlying causes of exploits that are laid bare in their own research.

There are currently 40 posts on the Project Zero blog, dating back to July 2013. They have documented or mentioned many vulnerabilities in that time. These vulnerabilities fall into the following categories:

• Memory safety bugs (use-after-free, type confusion, heap overflow, buffer overflow, integer overflow, etc.)
• Sandbox escapes
• Information leakages
• Hardware attacks
• Timing attacks

The categories that they discuss most often, by far, are memory safety bugs, followed by sandbox escapes. Furthermore, most of the sandbox escapes are only useful after a memory safety bug has been exploited. In the words of one of the authors,

Sandboxes are one of the main areas of interest for Project Zero (and me in particular) as they are choke points for an attacker successfully exploiting a remote code execution vulnerability.

(A remote code execution vulnerability is almost always a memory safety violation.)

In other words, memory safety bugs are the important bugs.

Furthermore, the most effective way to prevent memory safety violations is to program in a safe programming language. Every attack researcher knows this, but few mention it. I can find no mention of this on the Project Zero blog, the public face of their project.

This isn’t just about my own pet solution. There’s very little discussion on their blog about other mitigations for memory safety vulnerabilities (except how to get around them). This is practically a dereliction of duty.

What should they do?

Consider the full disclosure argument made by many attack researchers, and Project Zero in particular. It says that vendors endanger their users by ignoring or actively burying vulnerability reports, so, reports should be made publicly regardless of whether the vendor has patched the bug.

The same argument can be made for programmers who endanger their users by writing programs in unsafe languages: these programmers should not be allowed to simply continue their reckless behavior without consequence.

The Project Zero blog, not to mention another 50 years of historical data, contains ample evidence that the problem comes from programs written in unsafe languages, and this deserves to be called out with every memory safety exploit.

Project Zero and other attack researchers who claim to be motivated by public safety are irresponsible if they only publicize their own bug hunting instead of promoting effective solutions.