Google wants Project Zero to be part of an open alliance

LAS VEGAS -- Five years and more than 1,600 vulnerability disclosures after Project Zero was formed, Google is looking to expand the organization through alliances with other attack research teams.

At Black Hat 2019, Ben Hawkes, Project Zero team lead, discussed the first five years of Project Zero and where Google hopes to see vulnerability research go in the future by creating a coalition of independent research teams. According to Hawkes, Project Zero had five founding principles in its effort to "make 0day hard." They were as follows:

• Good defense requires a detailed knowledge of offense, so Google would create a pipeline of work that mimics what an attacker would use.
• Attackers target the weakest link in the chain.
• Openness benefits defenders more than it benefits attackers.
• Challenging industry norms leads to improved security.

In order to support these goals, Project Zero was formed as a loose coalition of independent vulnerability researchers who were given "intellectual freedom" and autonomy to choose their own targets and abandon efforts as needed, Hawkes said. It was also designed to develop new methodologies, as long as they were either faster at finding bugs or found bugs that were previously hidden.

Hawkes said the majority of the time (54.2%), Project Zero researchers find new bugs via manual review -- meaning source code review or reverse-engineering a binary -- and 37.2% of bugs are found by fuzzing.

"It tends to be that Project Zero's contribution is more in terms of bespoke, artisanal fuzzing as opposed to taking the known tools and running them on a target," Hawkes said. "A lot of that work is about surfacing new ways to think about mutation generation, surfacing new ways to improve code coverage."

Beyond just finding the vulnerabilities, Hawkes told the conference crowd, Google also wanted to do more than just push for fixes to the bugs it found. Hawkes said Google's Project Zero "tends to be in the position to advocate for change," rather than just getting issues patched.

For example, Project Zero found more than 200 vulnerabilities in Adobe Flash. Beyond just working with Adobe and Microsoft to implement exploit mitigations, Project Zero worked with the Chrome team to lock down the plugin process of the browser to "break the canonical exploit chain" used with Flash bugs. Project Zero also worked to expedite "click-to-play," which in turn spurred the end-of-life of Flash.

Hawkes said the fundamental strategies of Project Zero likely won't change in the next five years, but there will be unpredictable shifts in focus based on the changing techniques of attackers.

"For some sets of vulnerabilities, we write exploits. A traditional reason [to do so] is to demonstrate the security impact of the vulnerability to make sure that's well understood. Extracting that idea one step [further] is to say with a fixed bug class in a fixed execution environment, if we write an exploit for that one instance within that class, it sets up equivalence where all other bugs in the same execution environment are going to be exploited in the same manner."