Half of the 18 'zero-day' bugs that were exploited before a patch was publicly available this year could have been prevented if only major software vendors created more thorough patches and did more testing.
That's the verdict of researchers at Google Project Zero (GPZ), which has so far counted 18 zero-day bugs in 2022 affecting Microsoft Windows, Apple iOS and WebKit, Google's Chromium and Pixel, and Atlassian's Confluence server.
GPZ only collects data about zero-day (0-day) flaws -- or bugs exploited by attackers before a patch is available -- in major software products, so the figure doesn't encompass all software 0-days.
SEE: Don't let your cloud cybersecurity choices leave the door open for hackers
Also, according to GPZ, there have only been four truly unique 0-days this year and that's because attackers can just tweak exploits to bypass superficial patches.
"At least half of the 0-days we've seen in the first six months of 2022 could have been prevented with more comprehensive patching and regression tests. On top of that, four of the 2022 0-days are variants of 2021 in-the-wild 0-days. Just 12 months from the original in-the-wild 0-day being patched, attackers came back with a variant of the original bug," Maddie Stone, a member of GPZ, writes in a blogpost.
She adds that at least half of the 0-days "are closely related to bugs we've seen before."
That lack of originality backs up a trend that Stone and others at Google have highlighted recently to recast discussions about 0-days.
More 0-days were found in 2021 than in the past five years that GPZ has counted them. Several factors are potentially at play. First, researchers could be better at detecting them being exploited in the wild than previously. On the other hand, code-bases for browsers have become as complex as operating systems. Also, browsers have become a top target, thanks to the demise of browser plugins like Flash Player.
But while detection, disclosure and patching are improving across the industry, Stone has previously argued that the industry is "not making 0-day hard". She wants the industry to wipe out entire classes of security flaws.
For example, 67% of the 58 in-the-wild 0-days in 2021 were memory corruption vulnerabilities.
The Chrome security team is working on solutions for memory flaws stemming from the browser's huge code-base written in C++, but mitigations come at a performance cost. Chrome can't practically just be rewritten in Rust, which offers better memory safety guarantees than C and C++.
SEE: These hackers are spreading ransomware as a distraction - to hide their cyber spying
Stone also points out that Microsoft's Windows team and Google's Chrome team have supplied patches that are mere sticking-plasters.
"Many of the 2022 in-the-wild 0-days are due to the previous vulnerability not being fully patched. In the case of the Windows win32k and the Chromium property access interceptor bugs, the execution flow that the proof-of-concept exploits took were patched, but the root cause issue was not addressed: attackers were able to come back and trigger the original vulnerability through a different path," she says.
"And in the case of the WebKit and Windows PetitPotam issues, the original vulnerability had previously been patched, but at some point regressed so that attackers could exploit the same vulnerability again."
These are the 0-days GPZ has tracked this year up to June 15.
2022 ITW 0-day
CVE-2021-1732 (2021 itw)
CVE-2021-30983 (2021 itw)
CVE-2021-40444 (2021 itw)
Chromium property access interceptors
CVE-2016-5128 CVE-2021-30551 (2021 itw) CVE-2022-1232 (Addresses incomplete CVE-2022-1096 fix)
Bug was originally fixed in 2013, patch was regressed in 2016
* While this CVE says 2021, the bug was patched and disclosed in 2022
CVE-2021-36942 (Patch regressed)