LAS VEGAS - In the 10 years since Google’s Project Zero security research team was formed, progress has been made in the group’s motto of “making zero day hard” in some areas - but the fact that in-the-wild exploits still exist highlights the fact that the industry still has a ways to go.
Many of the same main issues shaping the zero-day landscape that existed in 2014 still remain today, including challenges around the quality of software, patching, transparency and mitigations. Vendors have an important part in improving these problems, said Natalie Silvanovich, team lead and security engineer with Google.
“It’s becoming increasingly apparent that security research is not enough to end the era of zero days,” said Silvanovich at a session here at Black Hat USA. “We’re not in the place to make the next big changes that need to happen to protect users from zero days. Vendors are. This is not an easy task, and many vendors have made a lot of progress since we started. But there is so much left to do.”
The fundamental understanding of zero days, how they are used and how organizations can prevent them was very different 10 years ago. Organizations didn’t understand underlying security problems in their software and lacked technical information. Patching was slower, and there were no clear protocols around patching and disclosure. Conversations around security incidents were less transparent, and relationships with researchers in some cases were hostile.
The researcher community has played a pivotal role in moving the needle on several of these challenges, said Silvanovich. For example, a number of zero days found in Adobe Flash between 2014 and 2015 - fueled in part by more researcher reports, the 2015 Pwn2Own competition and a leak of confidential material for spyware vendor Hacking Team that showed it had access to an unpatched Flash bug - led up to Flash being deprecated in 2020.
“It’s becoming increasingly apparent that security research is not enough to end the era of zero days."
Another win is the work that researchers have done in developing disclosure timelines for zero days. Google Project Zero’s 90-day disclosure policy - though unpopular with organizations at the start - did eventually light a fire under companies to be better about patching their zero days. Between 2019 and 2021, up to 93.4 percent of the issues reported by Project Zero to vendors were fixed under its standard 90-day deadline.
However, challenges in these areas remain. Researchers still see inconsistent patching habits with Android and the surrounding OEM community, including GPU and other third-party components, said Silvanovich. Another issue is that up to 40 percent of in-the-wild zero days flaws are variants of existing flaws, meaning that they are similar to flaws already fixed in software. This could indicate that vendors are rushing into fixes for their zero days as a result of pressure and time constants. As a result, they are producing incomplete fixes and aren’t addressing the root cause issue behind the flaw.
A new issue has cropped up over the recent years, as well: A security gap between the “best we see and the worst we see is large and growing,” she said. The worst offending companies in this area appear to be “middle-ware,” or firmware and software sold to upstream vendors, and attackers appear to be increasingly targeting these areas, said Silvanovich.
Vendors developing security programs should understand first and foremost, that bugs are the root causes of zero days and companies should fix all vulnerabilities in their software quickly and completely. They should also acknowledge that mitigations are not a substitute for a fix. And finally, vendors need to understand the importance of transparency, said Silvanovich.
“Project Zero plans to keep pushing, expanding our understanding of zero days, keeping vendors transparent and putting pressure on industry moving forward,” said Silvanovich. “But we need others to act. It will take all of us to end the era of zero days.”