back to article Google tracked record 58 exploited-in-the-wild zero-day security holes in 2021

Google's bug hunters say they spotted 58 zero-day vulnerabilities being exploited in the wild last year, which is the most-ever recorded since its Project Zero team started analyzing these in mid-2014. This is more than double the earlier record of 28 zero-day exploits detected in 2015. And miscreants are still using the same …

  1. A Non e-mouse Silver badge
    Happy

    Jam Hot.

  2. Anonymous Coward
    Anonymous Coward

    “I Like Money”

    - Frito

  3. Potemkine! Silver badge
    Mushroom

    17 use-after-free()

    6 out-of-bounds read & write

    4 buffer overflow

    4 integer overflow

    :doh: ! All of these are devs' blunders.

    If you don't know how to manage memory correctly, go back to school or find another job.

    1. Kabukiwookie

      Of the 52, Chromium/Chrome (14) had the most, followed by Windows (10), Safari (7), Android (7), Microsoft Exchange Server (5), Internet Explorer (4) and macOS/iOS (5).

      So the most notable zero-days came from Google, MS and Apple.

      1. Jim Mitchell

        Is that due to zero-days in other products not being detected, not being disclosed, or not existing?

      2. DS999 Silver badge

        The more your products are being used, the more effort that will be placed into looking for zero days. There might be a bunch of zero days waiting to be found in say Opera, but its userbase is so small compared to Chrome that it isn't worth the investment on the part of bad guys to find them.

        Millions clearly went into developing that NSO iOS Pegasus exploit, because there are so many iPhones (especially among the world leaders and other elites who NSO's customers wanted to target) If those people were all still using Blackberries like they were 10-15 years ago the over half dozen pieces of that long exploit chain would still be sitting inside iOS unknown and unfixed.

        It also has to do with how complex modern smartphone OSes, modern browsers, etc. are. The more lines of code, the more functions, the more subsystems that interact with each other in unknown ways, the more legacy code (like the Fax era JBIG2 code hiding in a little open source library Apple used for GIF decoding) that can't be removed because there are still a few people using it the more attack surface there is.

    2. the spectacularly refined chap Silver badge

      :doh: ! All of these are devs' blunders.

      Of course, this suprises you? What did you expect them to be?

      If you don't know how to manage memory correctly, go back to school or find another job.

      If you think this stuff is simple perhaps you are the one that needs to go back to school until you at least grasp the scope and complexities of the problem.

      1. Potemkine! Silver badge

        I developed software long enough to know what I'm talking about, thank you.

        Somebody using null pointer or writing outside the bounds of an array isn't a developer, it's a code-pissing monkey.

  4. Claptrap314 Silver badge

    The industry is a sewer

    Exploit hunters are the bacteria (good and bad) growing in there.

    Project Zero was created by Google to embarrass the competition into getting their act together.

    Guess which provider is doing the worst at having their act together according to Project Zero's (admittedly extremely rough) metric?

    But the core issue boils down to three facts:

    1) Companies exist to make money for their shareholders.

    2) Security is expensive.

    3) Consumers have no ability to evaluate security.

    My least-favorite tool to fix problems is the government. But I don't see any other way to address this.

    1. DS999 Silver badge

      Re: The industry is a sewer

      It is difficult to compare using its metrics because unless something is publicly reported you have to rely on the OEM to file a CVE. Apple does, even for stuff it finds internally that it has no evidence has ever been exploited. I think Microsoft does now, but they didn't used to, which made their numbers look better in the past.

      It also depends on how you count, as the same bug may be in multiple products that share source code. Is a bug in source shared by iOS and macOS one bug or two? If the impact is identical maybe it is covered under one CVE, but if the impact differs it may be filed as separate CVEs.

      So I wouldn't read anything into the counts other than "everyone has too damn many!"

    2. cyberdemon Silver badge
      Mushroom

      Re: The industry is a sewer

      > My least-favorite tool to fix problems is the government. But I don't see any other way to address this.

      Agreed.

      One thing that "the government" could do for example, is to restrict JavaScript in the same way that they restrict Cookies.

      Browsers should be forced to block all JavaScript that did not come from the original publisher of a webpage, except by explicit individual consent of the user.

      The reason that this would need support from "the government" of course, is because it would seriously impinge on Google, Amazon, Facebook et al's ability to collect data from their data cows users.

      No longer would you have a bunch of javascripts from googletagmanager.com, googlesyndication.com etc that you don't want with your webpage and which are doing nothing useful except collecting data about you on behalf of google, or worse, scripts from some hacked or outright malicious third-party that are exploiting one or more of Google's numerous zero-day vulnerabilities to steal your passwords, draw over your screen etc. on the behalf of the FSB, Mossad, the CCP or your local friendly scamware gang.

      1. Claptrap314 Silver badge

        Re: The industry is a sewer

        As a programmer, limiting js to first-party is such an easy step to bypass, I'm uncomfortable even advocating for it. What's the difference, from the standpoint of end user security, between googletagmanager.com/slurp.js and /googletagmanager.com/slurp.js?

  5. fg_swe Silver badge

    C and C++ Caused 70% of these Issues

    Time and again, a lack of memory safety creates plenty of exploitable bugs.

    Here is a systematic fix, as opposed to band-aids: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf

    And no, there are NO perfect programmers/software engineers who will write bugfree code.

    1. Claptrap314 Silver badge

      Re: C and C++ Caused 70% of these Issues

      I've had a couple of mid-sized undertakings that were bug-free.

      1) The requirements for the projects were fixed throughout.

      2) I have been accepted into the PhD program at a class I institution.

      3) The projects were not large.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like