Possible use after free due to improper handling of memory mapping of multiple processes simultaneously. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables
{"attackerkb": [{"lastseen": "2022-10-04T23:06:36", "description": "Possible use after free due to improper handling of memory mapping of multiple processes simultaneously. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables\n\n \n**Recent assessments:** \n \nAssessed Attacker Value: 0 \nAssessed Attacker Value: 0Assessed Attacker Value: 0\n", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-05-07T00:00:00", "type": "attackerkb", "title": "CVE-2021-1905", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1905"], "modified": "2021-05-13T00:00:00", "id": "AKB:B0D45425-6D7E-4251-BCA3-D03D8F4E38F9", "href": "https://attackerkb.com/topics/wbsz1xIyiy/cve-2021-1905", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "cisa_kev": [{"lastseen": "2022-08-10T17:26:47", "description": "Possible use after free due to improper handling of memory mapping of multiple processes simultaneously", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-11-03T00:00:00", "type": "cisa_kev", "title": "Qualcomm Use-After-Free Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1905"], "modified": "2021-11-03T00:00:00", "id": "CISA-KEV-CVE-2021-1905", "href": "", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "malwarebytes": [{"lastseen": "2021-05-20T18:28:42", "description": "In the Android Security Bulletin of May 2021, published at the beginning of this month, you can find a list of roughly 40 vulnerabilities in several components that might concern Android users. According to info provided by Google's Project Zero team, four of those Android security vulnerabilities are being exploited in the wild as zero-day bugs.\n\nThe good news is that patches are available. The problem with Android patches and updates though is that you, as a user, are dependent on your upstream provider for when these patches will reach your system.\n\n### Android updates and upgrades\n\nIt is always unclear for Android users when they can expect to get the latest updates and upgrades. An Android device is a computer in many regards and it needs regular refreshes. Either to patch against the latest vulnerabilities or when new features become available.\n\nAn update is when an existing Android version gets improved, and these come out regularly. An upgrade is when your device gets a later Android version. Usually a device can function just fine without getting an upgrade as long as it stays safe by getting the latest updates.\n\n### Depends on brand and type\n\nGoogle is the company that developed the Android operating system (which is itself a type of Linux) and the company also keeps it current. It is also the company that creates the security patches. But then the software is turned over to device manufacturers that create their own versions for their own devices.\n\nSo, when (even if) you will get the latest updates at all, depends on the manufacturer of your device. Some manufacturer\u2019s devices may never see another update because Google is not allowed to do business with them.\n\n### The critical vulnerabilities\n\nIn a note, the bulletin states that there are indications that CVE-2021-1905, CVE-2021-1906, CVE-2021-28663, and CVE-2021-28664 may be under limited, targeted exploitation. Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. The four that may be being abused in the wild are:\n\n * [CVE-2021-1905](<https://nvd.nist.gov/vuln/detail/CVE-2021-1905>) Possible use after free due to improper handling of memory mapping of multiple processes simultaneously. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables.\n * [CVE-2021-1906](<https://nvd.nist.gov/vuln/detail/CVE-2021-1906>) Improper handling of address de-registration on failure can lead to new GPU address allocation failure. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables.\n * [CVE-2021-28663](<https://nvd.nist.gov/vuln/detail/CVE-2021-28663>) The Arm Mali GPU kernel driver allows privilege escalation or information disclosure because GPU memory operations are mishandled, leading to a use-after-free. This affects Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r4p0 through r30p0.\n * [CVE-2021-28664](<https://nvd.nist.gov/vuln/detail/CVE-2021-28664>) The Arm Mali GPU kernel driver allows privilege escalation or a denial of service (memory corruption) because an unprivileged user can achieve read/write access to read-only pages. This affects Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r8p0 through r30p0.\n\nUse after free (UAF) like CVE-2021-1905 is a vulnerability caused by incorrect use of dynamic memory during a program\u2019s operation. If after freeing a memory location, a program does not clear the pointer to that memory, an attacker can use the error to manipulate the program.\n\nSnapdragon is a suite of system on a chip (SoC) semiconductor products for mobile devices designed and marketed by Qualcomm Technologies Inc.\n\nArm Mali GPU is a graphics processing unit for a range of mobile devices from smartwatches to autonomous vehicles developed by Arm.\n\n### Mitigation\n\nYou can tell whether your device is protected by [checking the security patch level](<https://support.google.com/android/answer/7680439?hl=en>).\n\n * Security patch levels of 2021-05-01 or later address all issues associated with the 2021-05-01 security patch level.\n * Security patch levels of 2021-05-05 or later address all issues associated with the 2021-05-05 security patch level and all previous patch levels.\n\nWe would love to tell you to patch urgently, but as we explained, this depends on the manufacturer. Some users who haven't switched to new devices that still receive monthly security updates might even not be able to install these patches at all.\n\nStay safe, everyone!\n\nThe post [Android patches for 4 in-the-wild bugs are out, but when will you get them?](<https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/05/android-patches-for-4-in-the-wild-bugs-are-out-but-when-will-you-get-them/>) appeared first on [Malwarebytes Labs](<https://blog.malwarebytes.com>).", "edition": 2, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-05-20T17:13:53", "type": "malwarebytes", "title": "Android patches for 4 in-the-wild bugs are out, but when will you get them?", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1905", "CVE-2021-1906", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-05-20T17:13:53", "id": "MALWAREBYTES:EB04567CC0DCC2AA6FDDD6A780E6AFE7", "href": "https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/05/android-patches-for-4-in-the-wild-bugs-are-out-but-when-will-you-get-them/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "thn": [{"lastseen": "2022-05-09T12:38:02", "description": "[](<https://thehackernews.com/images/--bQd_wXz_co/YKXvNNPXGpI/AAAAAAAAClU/c5Se7viT_Ewh2TJZaiUOQmpA_FBdof58QCLcBGAsYHQ/s0/ANDROID.jpg>)\n\nGoogle on Wednesday updated its May 2021 Android Security Bulletin to disclose that four of the security vulnerabilities that were patched earlier this month by Arm and Qualcomm may have been exploited in the wild as zero-days.\n\n\"There are indications that CVE-2021-1905, CVE-2021-1906, CVE-2021-28663 and CVE-2021-28664 may be under limited, targeted exploitation,\" the search giant [said](<https://source.android.com/security/bulletin/2021-05-01>) in an updated alert.\n\nThe four flaws impact [Qualcomm Graphics](<https://www.qualcomm.com/company/product-security/bulletins/may-2021-bulletin>) and [Arm Mali GPU Driver](<https://developer.arm.com/support/arm-security-updates/mali-gpu-kernel-driver>) modules \u2014\n\n * **CVE-2021-1905** (CVSS score: 8.4) - A use-after-free flaw in Qualcomm's graphics component due to improper handling of memory mapping of multiple processes simultaneously.\n * **CVE-2021-1906** (CVSS score: 6.2) - A flaw concerning inadequate handling of address deregistration that could lead to new GPU address allocation failure.\n * **CVE-2021-28663** (CVSS score: NA) - A vulnerability in Arm Mali GPU kernel that could permit a non-privileged user to make improper operations on GPU memory, leading to a use-after-free scenario that could be exploited to gain root privilege or disclose information. \n * **CVE-2021-28664** (CVSS score: NA) - An unprivileged user can achieve read/write access to read-only memory, enabling privilege escalation or a denial-of-service (DoS) condition due to memory corruption.\n\nSuccessful exploitation of the weaknesses could grant an adversary carte blanche access to the targeted device and take over control. It's, however, not clear how the attacks themselves were carried out, the victims that may have been targeted, or the threat actors that may be abusing them.\n\nThe development marks one of the rare instances where zero-day bugs in Android have been spotted in real-world cyber offensives.\n\nEarlier this March, Google revealed that a vulnerability affecting Android devices that use Qualcomm chipsets ([CVE-2020-11261](<https://thehackernews.com/2021/03/warning-new-android-zero-day.html>)) was being weaponized by adversaries to launch targeted attacks. The other flaw is [CVE-2019-2215](<https://nvd.nist.gov/vuln/detail/CVE-2019-2215>), a vulnerability in [Binder](<https://developer.android.com/reference/android/os/Binder>) \u2014 Android's inter-process communication mechanism \u2014 that's said to have been allegedly exploited by the NSO Group as well as [SideWinder threat actor](<https://www.trendmicro.com/en_us/research/20/a/first-active-attack-exploiting-cve-2019-2215-found-on-google-play-linked-to-sidewinder-apt-group.html>) to compromise a victim's device and collect user information.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-05-20T05:13:00", "type": "thn", "title": "Android Issues Patches for 4 New Zero-Day Bugs Exploited in the Wild", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-2215", "CVE-2020-11261", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-05-20T05:35:42", "id": "THN:9CE461E69A8B499207911497E3A349FD", "href": "https://thehackernews.com/2021/05/android-issues-patches-for-4-new-zero.html", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2022-05-09T12:38:08", "description": "[](<https://thehackernews.com/new-images/img/a/AVvXsEiH_ku-QrzXLuWobEQwNeCU-1szXQE_YfU7-27jchcPvQch2oAG-unVPYTeIA9mD8dCRQKYOdycKdKQejYSAQDLOBNrC8o_iHMZtXakx0WEiJMrBaV54fvlywQNqzISF_c_16nYrItctTkviCxzwdXakAUJttFAEPo3UwwTfqKrp6jng_lB8VtW0jt9>)\n\nGoogle has rolled out its monthly security patches for Android with fixes for 39 flaws, including a zero-day vulnerability that it said is being actively exploited in the wild in limited, targeted attacks.\n\nTracked as **CVE-2021-1048**, the zero-day bug is described as a [use-after-free vulnerability](<https://cwe.mitre.org/data/definitions/416.html>) in the kernel that can be exploited for local privilege escalation. Use-after-free issues are dangerous as it could enable a threat actor to access or referencing memory after it has been freed, leading to a \"[write-what-where](<https://cwe.mitre.org/data/definitions/123.html>)\" condition that results in the execution of arbitrary code to gain control over a victim's system.\n\n\"There are indications that CVE-2021-1048 may be under limited, targeted exploitation,\" the company [noted](<https://source.android.com/security/bulletin/2021-11-01>) in its November advisory without revealing technical details of the vulnerability, the nature of the intrusions, and the identities of the attackers that may have abused the flaw.\n\nAlso remediated in the security patch are two critical remote code execution (RCE) vulnerabilities \u2014 CVE-2021-0918 and CVE-2021-0930 \u2014 in the System component that could allow remote adversaries to execute malicious code within the context of a privileged process by sending a specially-crafted transmission to targeted devices.\n\nTwo more critical flaws, CVE-2021-1924 and CVE-2021-1975, affect Qualcomm closed-source components, while a fifth critical vulnerability in Android TV (CVE-2021-0889) could permit an attacker in close proximity to silently pair with a TV and execute arbitrary code with no privileges or user interaction required.\n\nWith the latest round of updates, Google has addressed a [total](<https://thehackernews.com/2021/03/warning-new-android-zero-day.html>) of [six zero-days](<https://thehackernews.com/2021/05/android-issues-patches-for-4-new-zero.html>) in Android since the start of the year \u2014\n\n * [**CVE-2020-11261**](<https://nvd.nist.gov/vuln/detail/CVE-2020-11261>) (CVSS score: 8.4) - Improper input validation in Qualcomm Graphics component\n * [**CVE-2021-1905**](<https://nvd.nist.gov/vuln/detail/CVE-2021-1905>) (CVSS score: 8.4) - Use-after-free in Qualcomm Graphics component\n * [**CVE-2021-1906**](<https://nvd.nist.gov/vuln/detail/CVE-2021-1906>) (CVSS score: 6.2) - Detection of error condition without action in Qualcomm Graphics component\n * [**CVE-2021-28663**](<https://nvd.nist.gov/vuln/detail/CVE-2021-28663>) (CVSS score: 8.8) - Mali GPU Kernel Driver allows improper operations on GPU memory\n * [**CVE-2021-28664**](<https://nvd.nist.gov/vuln/detail/CVE-2021-28664>) (CVSS score: 8.8) - Mali GPU Kernel Driver elevates CPU RO pages to writable\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-11-03T05:20:00", "type": "thn", "title": "Google Warns of New Android 0-Day Vulnerability Under Active Targeted Attacks", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11261", "CVE-2021-0889", "CVE-2021-0918", "CVE-2021-0930", "CVE-2021-1048", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-1924", "CVE-2021-1975", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-11-03T05:20:12", "id": "THN:37E4ECDE5CC5E074EC9FD4DF79D85121", "href": "https://thehackernews.com/2021/11/google-warns-of-new-android-0-day.html", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "threatpost": [{"lastseen": "2021-05-21T14:02:25", "description": "Google updated its May 3 Android security [bulletin](<https://source.android.com/security/bulletin/2021-05-01#mitigations>) on Wednesday to say that there are \u201cindications\u201d that four of the 50 vulnerabilities \u201cmay be under limited, targeted exploitation.\u201d That was mostly confirmed by Maddie Stone, a member of Google\u2019s Project Zero exploit research group, who clarified on Twitter that the \u201c4 vulns were exploited in-the-wild\u201d as zero-days.\n\n> Android has updated the May security with notes that 4 vulns were exploited in-the-wild. \n> \n> Qualcomm GPU: CVE-2021-1905, CVE-2021-1906 \nARM Mali GPU: CVE-2021-28663, CVE-2021-28664<https://t.co/mT8vE2Us74>\n> \n> \u2014 Maddie Stone (@maddiestone) [May 19, 2021](<https://twitter.com/maddiestone/status/1395004346996248586?ref_src=twsrc%5Etfw>)\n\nGoogle Android exploits are a rarity. These four bugs make up a full two-thirds of the six total bugs to be exploited in the wild since 2014, according to Google\u2019s tracking [spreadsheet](<https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1123292625>). Project Zero\u2019s Stone went on to celebrate that fact, pointing out that \u201cFor 2021, we\u2019ve surpassed the number of 0-days detected in-the-wild in all of 2020. That\u2019s great!\u201d\n\nAccording to security firm Zimperium, Google disclosed only one zero-day vulnerability in Android in 2020.\n\n## Could Give Attackers \u2018Complete Control\u2019 of Androids\n\nIs finding four zero-days really all that great? These four bugs could give attackers complete control of Android devices. All four affect GPU firmware code. Two of the bugs impact the ARM Mali GPU driver, while the other two are found in the Qualcomm Snapdragon CPU graphics component.\n\nCVE | Description \n---|--- \n[CVE-2021-1905](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1905>) | Possible use after free due to improper handling of memory mapping of multiple processes simultaneously. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables. \n[CVE-2021-1906](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1906>) | Improper handling of address deregistration on failure can lead to new GPU address allocation failure. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables. \n[CVE-2021-28663](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28663>) | The Arm Mali GPU kernel driver allows privilege escalation or information disclosure because GPU memory operations are mishandled, leading to a use-after-free. This affects Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r4p0 through r30p0. \n[CVE-2021-28664](<http://CVE-2021-28664>) | The Arm Mali GPU kernel driver allows privilege escalation or a denial of service (memory corruption) because an unprivileged user can achieve read/write access to read-only pages. This affects Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r8p0 through r30p0. \n \nAsaf Peleg, vice president of strategic projects for Zimperium, told [Ars Technica](<https://arstechnica.com/gadgets/2021/05/hackers-have-been-exploiting-4-critical-android-vulnerabilities/>) that successful exploits of the vulnerabilities \u201cwould give complete control of the victim\u2019s mobile endpoint. From elevating privileges beyond what is available by default to executing code outside of the current process\u2019s existing sandbox, the device would be fully compromised, and no data would be safe.\u201d\n\nThis is the second time this month that Qualcomm has suffered chip woes. As Check Point Research reported in early May, a vulnerability in a 5G modem data service could allow a malicious app to exploit the issue, opening up Android phones to [attackers being able to eavesdrop](<https://threatpost.com/qualcomm-chip-bug-android-eavesdropping/165934/>), inject, malicious code into a phone\u2019s modem, access call histories and text messages: a problem that could affect up to 30 percent of Android phones.\n\n## One Exploit May Be Tied to Spyware Maker NSO Group\n\nAs [The Record](<https://therecord.media/arm-and-qualcomm-zero-days-quietly-patched-in-this-months-android-security-updates/>) reported, two of the zero-days have previously been exploited in the wild: [CVE-2020-11261](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11261>), a bug in the Qualcomm graphics component that was patched in the [January 2021 Android security bulletin](<https://source.android.com/security/bulletin/2021-01-01>), and [CVE-2019-2215](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2215>), an Android exploit that Project Zero believes was [developed by exploit broker NSO Group](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1942>) and was allegedly being used, abused and sold to its customers throughout 2019.\n\nNSO Group, an Israeli maker of the Pegasus mobile spyware tool, [has long insisted](<https://threatpost.com/nso-group-president-defends-controversial-tactics/150694/>) that its products are meant to be used to fight crime and terror. Whatever governments do with it, NSO Group isn\u2019t in on it, the company has said. That contention was dissected in court in July 2020, during Facebook\u2019s lawsuit over [alleged spying on WhatsApp users.](<https://threatpost.com/facebooks-nso-group-lawsuit-whatsapp-spying/157571/>)\n\n\n\nAt the time, Judge Phyllis Hamilton said that it appears that NSO Group \u201cretained some role\u201d in how its wares are used. She also pointed to a statement to the court from CEO Shalev Hulio, which says that NSO Group carries out its activities \u201centirely at the direction of their government customers,\u201d and that it provides \u201cadvice and technical support\u201d for its notorious Pegasus, which is a remote access trojan (RAT). The tool enables governments to send a personalized text message with an infected link to a blank page. Click on it, whether it be on an iOS or Android phone, and the software gains full control over the targeted device, monitoring all messaging, contacts and calendars, and possibly even turning on microphones and cameras for surveillance purposes.\n\nAs far as whether NSO Group is behind these Android zero-day exploits, the sophistication required to exploit these vulnerabilities would be in line with its history. \u201cThe complexity of this mobile attack vector is not unheard of but is outside the capabilities of an attacker with rudimentary or even intermediate knowledge of mobile endpoint hacking,\u201d Peleg said. \u201cAny attacker using this vulnerability is most likely doing so as part of a larger campaign against an individual, enterprise, or government with the goal of stealing critical and private information.\u201d\n\n## How Should Android Fans Protect Themselves?\n\nOnly Android phones that use Arm or Qualcomm GPUs are affected by these bugs. According to recent [Arm](<https://developer.arm.com/support/arm-security-updates/mali-gpu-kernel-driver>) and [Qualcomm](<https://www.qualcomm.com/company/product-security/bulletins/may-2021-bulletin>) security bulletins each of their respected chipsets are impacted. Sources told The Record that this month\u2019s security updates may have been delayed by some smartphone vendors to make sure they shipped the Arm and Qualcomm fixes released on Wednesday.\n\nCheck Point Security Technologies\u2019 Head of Cyber Research, Yaniv Balmas, said via email that \u201cQualcomm, as one of the world\u2019s biggest chip manufacturers, also needs to deal with many security issues found on their products (both internally and externally). This not different than any other vendor of that size. Obviously, bugs found in Qualcomm mobile chips can cause security issues in their hosting devices and operating systems, which is mainly Android.\u201d\n\nThese security issues were found on Qualcomm\u2019s GPU chips, which provide \u201ca very large attack surface,\u201d Balmas told Threatpost. adding that \u201cSuccessful exploitation may lead to a complete phone compromise.\u201d\n\nThreatpost has reached out to Google, NVIDIA ARM and Qualcomm for input on how Android users should proceed.\n\n052121 09:58 UPDATE: Added input from Yaniv Balmas.\n\n**Download our exclusive FREE Threatpost Insider eBook, ****_\u201c_**[**_2021: The Evolution of Ransomware_**](<https://threatpost.com/ebooks/2021-the-evolution-of-ransomware/?utm_source=April_eBook&utm_medium=ART&utm_campaign=ART>)**_,\u201d_**** to help hone your cyber-defense strategies against this growing scourge. We go beyond the status quo to uncover what\u2019s next for ransomware and the related emerging risks. Get the whole story and **[**DOWNLOAD**](<https://threatpost.com/ebooks/2021-the-evolution-of-ransomware/?utm_source=April_eBook&utm_medium=ART&utm_campaign=ART>)** the eBook now \u2013 on us!**\n", "cvss3": {}, "published": "2021-05-20T16:50:16", "type": "threatpost", "title": "4 Android Bugs Being Exploited in the Wild", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-2215", "CVE-2020-11261", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-05-20T16:50:16", "id": "THREATPOST:38BE049C6C451ED1B9E3037B2EA65D9A", "href": "https://threatpost.com/android-bugs-exploited-wild/166347/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "androidsecurity": [{"lastseen": "2022-09-08T00:19:42", "description": "The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2021-05-05 or later address all of these issues. To learn how to check a device's security patch level, see [Check and update your Android version](<https://support.google.com/pixelphone/answer/4457705>).\n\nAndroid partners are notified of all issues at least a month before publication. Source code patches for these issues have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP. \n\nThe most severe of these issues is a critical security vulnerability in the System component that could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed. \n\nRefer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform. \n\n**Note**: Information on the latest over-the-air update (OTA) and firmware images for Google devices is available in the May 2021 Pixel Update Bulletin. \n\n## Android and Google service mitigations\n\nThis is a summary of the mitigations provided by the Android security platform and service protections such as [Google Play Protect](<https://developers.google.com/android/play-protect>). These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android. \n\n * Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.\n * The Android security team actively monitors for abuse through [Google Play Protect](<https://developers.google.com/android/play-protect>) and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with [Google Mobile Services](<http://www.android.com/gms>), and is especially important for users who install apps from outside of Google Play.\n**Note**: There are indications that CVE-2021-1905, CVE-2021-1906, CVE-2021-28663 and CVE-2021-28664 may be under limited, targeted exploitation. \n\n## 2021-05-01 security patch level vulnerability details\n\nIn the sections below, we provide details for each of the security vulnerabilities that apply to the 2021-05-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as [Google Play system updates](<https://support.google.com/android/answer/7680439>). \n\n### Framework\n\nThe most severe vulnerability in this section could enable a local malicious application to bypass user interaction requirements in order to gain access to additional permissions. \n\nCVE | References | Type | Severity | Updated AOSP versions \n---|---|---|---|--- \nCVE-2021-0472 | [A-176801033](<https://android.googlesource.com/platform/frameworks/base/+/c90fb352cdaab0fd5adaa8957694b726045c673c>) | EoP | High | 9, 10, 11 \nCVE-2021-0485 | [A-174302616](<https://android.googlesource.com/platform/frameworks/base/+/aad7fdc4f82ad56e332d3c23c5d07719e069b099>) | EoP | High | 11 \nCVE-2021-0487 | [A-174046397](<https://android.googlesource.com/platform/packages/providers/CalendarProvider/+/8cddb2643dd823721ba5c897a089d06c56b50a60>) | EoP | High | 11 \n \n### Media Framework\n\nThe most severe vulnerability in this section could enable a local malicious application to bypass user interaction requirements in order to gain access to additional permissions. \n\nCVE | References | Type | Severity | Updated AOSP versions \n---|---|---|---|--- \nCVE-2021-0482 | [A-173791720](<https://android.googlesource.com/platform/frameworks/av/+/57d90982aa7a18a8c76c8dcc418c8da51a71aa9d>) | EoP | High | 11 \nCVE-2021-0484 | [A-173720767](<https://android.googlesource.com/platform/frameworks/av/+/8e6748ee5b5363e660c81c0427c317b7a71a9181>) | ID | High | 8.1, 9, 10, 11 \n \n### System\n\nThe most severe vulnerability in this section could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process. \n\nCVE | References | Type | Severity | Updated AOSP versions \n---|---|---|---|--- \nCVE-2021-0473 | [A-179687208](<https://android.googlesource.com/platform/system/nfc/+/cd0f77f71ff4166529fc22aa7db6c32dbb1d2c1c>) | RCE | Critical | 8.1, 9, 10, 11 \nCVE-2021-0474 | [A-177611958](<https://android.googlesource.com/platform/system/bt/+/2cafe07d66bfc5cc75d7d2bf61415fc33d711132>) | RCE | Critical | 8.1, 9, 10, 11 \nCVE-2021-0475 | [A-175686168](<https://android.googlesource.com/platform/system/bt/+/a632a66b81ee4b1db65d0cf64b4ce525f56214ff>) | RCE | Critical | 10, 11 \nCVE-2021-0476 | [A-169252501](<https://android.googlesource.com/platform/system/bt/+/a2b86770143b3e6ec07a6f26edbdc2f8280f0463>) | EoP | High | 9, 10, 11 \nCVE-2021-0477 | [A-178189250](<https://android.googlesource.com/platform/frameworks/base/+/e01fef361bb7371e10b990737caed7a3799bdc3b>) | EoP | High | 8.1, 9, 10, 11 \nCVE-2021-0481 | [A-172939189](<https://android.googlesource.com/platform/packages/apps/Settings/+/d4f04398c71f67bc13f85e098e1dc71d840c1a4a>) | EoP | High | 8.1, 9, 10, 11 \nCVE-2021-0466 | [A-154114734](<https://android.googlesource.com/platform/frameworks/opt/net/wifi/+/9ce03caaec5f1612a4798ca48f9556c8198066f2>) | ID | High | 10 \nCVE-2021-0480 | [A-174493336](<https://android.googlesource.com/platform/frameworks/base/+/c024c5886aaf4fc98c53a761398fac5c399de789>) | ID | High | 8.1, 9, 10, 11 \n \n### Google Play system updates\n\nThere are no security issues addressed in Google Play system updates (Project Mainline) this month.\n\n## 2021-05-05 security patch level vulnerability details\n\nIn the sections below, we provide details for each of the security vulnerabilities that apply to the 2021-05-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. \n\n### Framework\n\nThe vulnerability in this section could enable a local malicious application to bypass operating system protections that isolate application data from other applications. \n\nCVE | References | Type | Severity | Updated AOSP versions \n---|---|---|---|--- \nCVE-2019-2219 | [A-119041698](<https://android.googlesource.com/platform/frameworks/base/+/d96f50a85f7762f50f672981c194ebb9e6ce4ff6>) | ID | High | 11 \n \n### Kernel components\n\nThe vulnerability in this section could enable a local attacker to bypass user interaction requirements in order to gain access to additional permissions. \n\nCVE | References | Type | Severity | Component \n---|---|---|---|--- \nCVE-2020-29661 | A-175451802 [Upstream kernel](<https://android.googlesource.com/kernel/common/+/54ffccbf053b5b6ca4f6e45094b942fab92a25fc>) | EoP | High | TTY \n \n### AMLogic\n\nThis vulnerability affects AMLogic components and further details are available directly from AMLogic. The severity assessment of this issue is provided directly by AMLogic. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2021-0467 | A-174490700* | | Critical | bootROM \n \n### ARM components\n\nThese vulnerabilities affect ARM components and further details are available directly from ARM. The severity assessment of these issues is provided directly by ARM. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2021-28663 | A-174259860* | | High | Mali \nCVE-2021-28664 | A-174588870* | | High | Mali \n \n### MediaTek components\n\nThese vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2021-0489 | A-183464866M-ALPS05403499* | | High | memory management driver \nCVE-2021-0490 | A-183464868M-ALPS05403499* | | High | memory management driver \nCVE-2021-0491 | A-183461315M-ALPS05403499* | | High | memory management driver \nCVE-2021-0492 | A-183459078M-ALPS05403499* | | High | memory management driver \nCVE-2021-0493 | A-183461317M-ALPS05403499* | | High | memory management driver \nCVE-2021-0494 | A-183461318M-ALPS05403499* | | High | memory management driver \nCVE-2021-0495 | A-183459083M-ALPS05403499* | | High | memory management driver \nCVE-2021-0496 | A-183467912M-ALPS05403499* | | High | memory management driver \nCVE-2021-0497 | A-183461320M-ALPS05403499* | | High | memory management driver \nCVE-2021-0498 | A-183461321M-ALPS05403499* | | High | memory management driver \n \n### Unisoc components\n\nThis vulnerability affects Unisoc components and further details are available directly from Unisoc. The severity assessment of this issue is provided directly by Unisoc. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2021-0324 | A-175402462* | | High | Framework \n \n### Qualcomm components\n\nThese vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2021-1891 | A-179039763 [QC-CR#2766242](<https://source.codeaurora.org/quic/la/platform/vendor/opensource/audio-kernel/commit/?id=97d18542c1972524964f2cfce6a3bd9abe8a1a35>) [[2](<https://source.codeaurora.org/quic/la/platform/vendor/opensource/audio-kernel/commit/?id=e4463e36c84b5fbf9aefc3f327aa4a7b8dc45f67>)] | | High | Audio \nCVE-2021-1905 | A-178809945[QC-CR#2826864](<https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=d236d315145f8250523ce9e14897d62e5d6639fc>) | | High | Display \nCVE-2021-1927 | A-179040600[QC-CR#2827356](<https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=85ecf9f98b520aa18e68ec426dc20fb63d02fd78>) | | High | Kernel \nCVE-2021-1906 | A-178810049[QC-CR#2835082](<https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit?id=2a576c81c8dfb800a239e60a1ee3352a0fb716a4>) | | Moderate | Display \n \n### Qualcomm closed-source components\n\nThese vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2020-11273 | A-172348952* | | High | Closed-source component \nCVE-2020-11274 | A-172348993* | | High | Closed-source component \nCVE-2020-11279 | A-172348857* | | High | Closed-source component \nCVE-2020-11284 | A-172348929* | | High | Closed-source component \nCVE-2020-11285 | A-172349029* | | High | Closed-source component \nCVE-2020-11288 | A-172348722* | | High | Closed-source component \nCVE-2020-11289 | A-172348852* | | High | Closed-source component \nCVE-2021-1910 | A-179039901* | | High | Closed-source component \nCVE-2021-1915 | A-172944461* | | High | Closed-source component \n \n## Common questions and answers\n\nThis section answers common questions that may occur after reading this bulletin.\n\n**1\\. How do I determine if my device is updated to address these issues?**\n\nTo learn how to check a device's security patch level, see [Check and update your Android version](<https://support.google.com/pixelphone/answer/4457705#pixel_phones&nexus_devices>).\n\n * Security patch levels of 2021-05-01 or later address all issues associated with the 2021-05-01 security patch level.\n * Security patch levels of 2021-05-05 or later address all issues associated with the 2021-05-05 security patch level and all previous patch levels.\n\nDevice manufacturers that include these updates should set the patch string level to:\n\n * [ro.build.version.security_patch]:[2021-05-01]\n * [ro.build.version.security_patch]:[2021-05-05]\n\nFor some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2021-05-01 security patch level. Please see [this article](<https://support.google.com/android/answer/7680439>) for more details on how to install security updates.\n\n**2\\. Why does this bulletin have two security patch levels?**\n\nThis bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.\n\n * Devices that use the 2021-05-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.\n * Devices that use the security patch level of 2021-05-05 or newer must include all applicable patches in this (and previous) security bulletins.\n\nPartners are encouraged to bundle the fixes for all issues they are addressing in a single update.\n\n**3\\. What do the entries in the _Type_ column mean?**\n\nEntries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.\n\nAbbreviation | Definition \n---|--- \nRCE | Remote code execution \nEoP | Elevation of privilege \nID | Information disclosure \nDoS | Denial of service \nN/A | Classification not available \n \n**4\\. What do the entries in the _References_ column mean?**\n\nEntries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.\n\nPrefix | Reference \n---|--- \nA- | Android bug ID \nQC- | Qualcomm reference number \nM- | MediaTek reference number \nN- | NVIDIA reference number \nB- | Broadcom reference number \n \n**5\\. What does an * next to the Android bug ID in the _References_ column mean?**\n\nIssues that are not publicly available have an * next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the [Google Developer site](<https://developers.google.com/android/drivers>). \n\n**6\\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**\n\nSecurity vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, [Huawei](<https://consumer.huawei.com/en/support/bulletin/>), [LGE](<https://lgsecurity.lge.com/security_updates_mobile.html>), [Motorola](<https://motorola-global-portal.custhelp.com/app/software-security-page/g_id/6806>), [Nokia](<https://www.nokia.com/phones/en_int/security-updates>), or [Samsung](<https://security.samsungmobile.com/securityUpdate.smsb>).\n\n## Versions\n\nVersion | Date | Notes \n---|---|--- \n1.0 | May 3, 2021 | Bulletin published. \n1.1 | May 4, 2021 | Bulletin revised to include AOSP links\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-05-03T00:00:00", "type": "androidsecurity", "title": "Android Security Bulletin\u2014May 2021", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-2219", "CVE-2020-11273", "CVE-2020-11274", "CVE-2020-11279", "CVE-2020-11284", "CVE-2020-11285", "CVE-2020-11288", "CVE-2020-11289", "CVE-2020-29661", "CVE-2021-0324", "CVE-2021-0466", "CVE-2021-0467", "CVE-2021-0472", "CVE-2021-0473", "CVE-2021-0474", "CVE-2021-0475", "CVE-2021-0476", "CVE-2021-0477", "CVE-2021-0480", "CVE-2021-0481", "CVE-2021-0482", "CVE-2021-0484", "CVE-2021-0485", "CVE-2021-0487", "CVE-2021-0489", "CVE-2021-0490", "CVE-2021-0491", "CVE-2021-0492", "CVE-2021-0493", "CVE-2021-0494", "CVE-2021-0495", "CVE-2021-0496", "CVE-2021-0497", "CVE-2021-0498", "CVE-2021-1891", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-1910", "CVE-2021-1915", "CVE-2021-1927", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-05-04T00:00:00", "id": "ANDROID:2021-05-01", "href": "https://source.android.com/docs/security/bulletin/2021-05-01", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "googleprojectzero": [{"lastseen": "2022-08-25T01:57:30", "description": "A Year in Review of 0-days Used In-the-Wild in 2021\n\nPosted by Maddie Stone, Google Project Zero\n\nThis is our third annual year in review of 0-days exploited in-the-wild [[2020](<https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html>), [2019](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>)]. Each year we\u2019ve looked back at all of the detected and disclosed in-the-wild 0-days as a group and synthesized what we think the trends and takeaways are. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a group, looking for trends, gaps, lessons learned, successes, etc. If you\u2019re interested in the analysis of individual exploits, please check out our [root cause analysis repository](<https://googleprojectzero.blogspot.com/p/rca.html>).\n\nWe perform and share this analysis in order to make 0-day hard. We want it to be more costly, more resource intensive, and overall more difficult for attackers to use 0-day capabilities. 2021 highlighted just how important it is to stay relentless in our pursuit to make it harder for attackers to exploit users with 0-days. We heard [over](<https://forbiddenstories.org/about-the-pegasus-project/>) and [over](<https://citizenlab.ca/2021/07/hooking-candiru-another-mercenary-spyware-vendor-comes-into-focus/>) and [over](<https://www.amnesty.org/en/latest/research/2021/11/devices-of-palestinian-human-rights-defenders-hacked-with-nso-groups-pegasus-spyware-2/>) about how governments were targeting journalists, minoritized populations, politicians, human rights defenders, and even security researchers around the world. The decisions we make in the security and tech communities can have real impacts on society and our fellow humans\u2019 lives.\n\nWe\u2019ll provide our evidence and process for our conclusions in the body of this post, and then wrap it all up with our thoughts on next steps and hopes for 2022 in the conclusion. If digging into the bits and bytes is not your thing, then feel free to just check-out the Executive Summary and Conclusion.\n\n# Executive Summary\n\n2021 included the detection and disclosure of 58 in-the-wild 0-days, the most ever recorded since Project Zero began tracking in mid-2014. That\u2019s more than double the previous maximum of 28 detected in 2015 and especially stark when you consider that there were only 25 detected in 2020. We\u2019ve tracked publicly known in-the-wild 0-day exploits in [this spreadsheet](<https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=0>) since mid-2014.\n\nWhile we often talk about the number of 0-day exploits used in-the-wild, what we\u2019re actually discussing is the number of 0-day exploits detected and disclosed as in-the-wild. And that leads into our first conclusion: we believe the large uptick in in-the-wild 0-days in 2021 is due to increased detection and disclosure of these 0-days, rather than simply increased usage of 0-day exploits.\n\nWith this record number of in-the-wild 0-days to analyze we saw that attacker methodology hasn\u2019t actually had to change much from previous years. Attackers are having success using the same bug patterns and exploitation techniques and going after the same attack surfaces. Project Zero\u2019s mission is \u201cmake 0day hard\u201d. 0-day will be harder when, overall, attackers are not able to use public methods and techniques for developing their 0-day exploits. When we look over these 58 0-days used in 2021, what we see instead are 0-days that are similar to previous & publicly known vulnerabilities. Only two 0-days stood out as novel: one for the technical sophistication of its exploit and the other for its use of logic bugs to escape the sandbox.\n\nSo while we recognize the industry\u2019s improvement in the detection and disclosure of in-the-wild 0-days, we also acknowledge that there\u2019s a lot more improving to be done. Having access to more \u201cground truth\u201d of how attackers are actually using 0-days shows us that they are able to have success by using previously known techniques and methods rather than having to invest in developing novel techniques. This is a clear area of opportunity for the tech industry.\n\nWe had so many more data points in 2021 to learn about attacker behavior than we\u2019ve had in the past. Having all this data, though, has left us with even more questions than we had before. Unfortunately, attackers who actively use 0-day exploits do not share the 0-days they\u2019re using or what percentage of 0-days we\u2019re missing in our tracking, so we\u2019ll never know exactly what proportion of 0-days are currently being found and disclosed publicly. \n\nBased on our analysis of the 2021 0-days we hope to see the following progress in 2022 in order to continue taking steps towards making 0-day hard:\n\n 1. All vendors agree to disclose the in-the-wild exploitation status of vulnerabilities in their security bulletins.\n 2. Exploit samples or detailed technical descriptions of the exploits are shared more widely.\n 3. Continued concerted efforts on reducing memory corruption vulnerabilities or rendering them unexploitable.Launch mitigations that will significantly impact the exploitability of memory corruption vulnerabilities.\n\n# A Record Year for In-the-Wild 0-days\n\n2021 was a record year for in-the-wild 0-days. So what happened?\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjC72HVhQEdwHNIzMiyb18bUFr6hPCWJiKL2Mm43-tW11qc0ucOPI8A9oChEXQe0-QNOBF83SIcfyjcyvPveuWvgipbiBzHWqZTx2-LilJFYIbx6uQeno9f481HJQ0CgylQkh8Ks7AbGC6tjhYDNBcI7jh6ihhzJATA0r_P4bQUBm-1lmHp2DPvWM6I/s1200/image1%287%29.png>)\n\nIs it that software security is getting worse? Or is it that attackers are using 0-day exploits more? Or has our ability to detect and disclose 0-days increased? When looking at the significant uptick from 2020 to 2021, we think it's mostly explained by the latter. While we believe there has been a steady growth in interest and investment in 0-day exploits by attackers in the past several years, and that security still needs to urgently improve, it appears that the security industry's ability to detect and disclose in-the-wild 0-day exploits is the primary explanation for the increase in observed 0-day exploits in 2021.\n\nWhile we often talk about \u201c0-day exploits used in-the-wild\u201d, what we\u2019re actually tracking are \u201c0-day exploits detected and disclosed as used in-the-wild\u201d. There are more factors than just the use that contribute to an increase in that number, most notably: detection and disclosure. Better detection of 0-day exploits and more transparently disclosed exploited 0-day vulnerabilities is a positive indicator for security and progress in the industry. \n\nOverall, we can break down the uptick in the number of in-the-wild 0-days into:\n\n * More detection of in-the-wild 0-day exploits\n * More public disclosure of in-the-wild 0-day exploitation\n\n## More detection\n\nIn the [2019 Year in Review](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>), we wrote about the \u201cDetection Deficit\u201d. We stated \u201cAs a community, our ability to detect 0-days being used in the wild is severely lacking to the point that we can\u2019t draw significant conclusions due to the lack of (and biases in) the data we have collected.\u201d In the last two years, we believe that there\u2019s been progress on this gap. \n\nAnecdotally, we hear from more people that they\u2019ve begun working more on detection of 0-day exploits. Quantitatively, while a very rough measure, we\u2019re also seeing the number of entities credited with reporting in-the-wild 0-days increasing. It stands to reason that if the number of people working on trying to find 0-day exploits increases, then the number of in-the-wild 0-day exploits detected may increase.\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMbFpoEKSSn5AbAzsovaZ0yN6_OFXo9u4hpDCXJBpro8LRUWJlVQ9CSqtzT2V9ohrhOvP3_RnrYsOzFGPK0FZGJmW2713g2vVW82ReJVXpjAZc57BCxtHg8i-6AdR_ThDZB6UKvzAKekbmAkuUBliMyDyWSBW87z4ZZQJC3KX-_ptZIHveotLGoJ9I/s1200/image5%284%29.png>)\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRS0t_2Bwvc3U_EIr5h7NcWpQyjzHCPb4OMiDpzPxPs587otAEj8bzwch8UMFlgKchwdSq4L_PXRn1O6KGLHUl4X9voLBdZJNQsgQyJcMCVB4Y8-aRHaXRpOYZw7KVtyNYwdWpwX8ILUV1fyG2kDsXVWORsSPUBGVTON90gWf9POhhxA4edxNe1eoV/s1200/image2%285%29.png>)\n\nWe\u2019ve also seen the number of vendors detecting in-the-wild 0-days in their own products increasing. Whether or not these vendors were previously working on detection, vendors seem to have found ways to be more successful in 2021. Vendors likely have the most telemetry and overall knowledge and visibility into their products so it\u2019s important that they are investing in (and hopefully having success in) detecting 0-days targeting their own products. As shown in the chart above, there was a significant increase in the number of in-the-wild 0-days discovered by vendors in their own products. Google discovered 7 of the in-the-wild 0-days in their own products and Microsoft discovered 10 in their products!\n\n## More disclosure\n\nThe second reason why the number of detected in-the-wild 0-days has increased is due to more disclosure of these vulnerabilities. Apple and Google Android (we differentiate \u201cGoogle Android\u201d rather than just \u201cGoogle\u201d because Google Chrome has been annotating their security bulletins for the last few years) first began labeling vulnerabilities in their security advisories with the information about potential in-the-wild exploitation in November 2020 and January 2021 respectively. When vendors don\u2019t annotate their release notes, the only way we know that a 0-day was exploited in-the-wild is if the researcher who discovered the exploitation comes forward. If Apple and Google Android had not begun annotating their release notes, the public would likely not know about at least 7 of the Apple in-the-wild 0-days and 5 of the Android in-the-wild 0-days. Why? Because these vulnerabilities were reported by \u201cAnonymous\u201d reporters. If the reporters didn\u2019t want credit for the vulnerability, it\u2019s unlikely that they would have gone public to say that there were indications of exploitation. That is 12 0-days that wouldn\u2019t have been included in this year\u2019s list if Apple and Google Android had not begun transparently annotating their security advisories. \n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPe_J-0Wu9Ap-0n3Yj5BoXiWTnjViyyGasIChhb3juADZosK9nTbyiaWtzuRyjwG3frQNjLsvRMRoQHrFfo1iKa3GjmcuLHqat40GcoechQ16XbhpVGwF7m_TJ0Oucvy3wvm8x0aXbVnJfhkG2FNkxI4cJf5ONBqEYnPxQDUmZChvByLHE8OzSU20N/s1200/image3%287%29.png>)\n\nKudos and thank you to Microsoft, Google Chrome, and Adobe who have been annotating their security bulletins for transparency for multiple years now! And thanks to Apache who also annotated their release notes for [CVE-2021-41773](<https://httpd.apache.org/security/vulnerabilities_24.html>) this past year. \n\nIn-the-wild 0-days in Qualcomm and ARM products were annotated as in-the-wild in Android security bulletins, but not in the vendor\u2019s own security advisories.\n\nIt's highly likely that in 2021, there were other 0-days that were exploited in the wild and detected, but vendors did not mention this in their release notes. In 2022, we hope that more vendors start noting when they patch vulnerabilities that have been exploited in-the-wild. Until we\u2019re confident that all vendors are transparently disclosing in-the-wild status, there\u2019s a big question of how many in-the-wild 0-days are discovered, but not labeled publicly by vendors.\n\n# New Year, Old Techniques\n\nWe had a record number of \u201cdata points\u201d in 2021 to understand how attackers are actually using 0-day exploits. A bit surprising to us though, out of all those data points, there was nothing new amongst all this data. 0-day exploits are considered one of the most advanced attack methods an actor can use, so it would be easy to conclude that attackers must be using special tricks and attack surfaces. But instead, the 0-days we saw in 2021 generally followed the same bug patterns, attack surfaces, and exploit \u201cshapes\u201d previously seen in public research. Once \u201c0-day is hard\u201d, we\u2019d expect that to be successful, attackers would have to find new bug classes of vulnerabilities in new attack surfaces using never before seen exploitation methods. In general, that wasn't what the data showed us this year. With two exceptions (described below in the iOS section) out of the 58, everything we saw was pretty \u201c[meh](<https://www.dictionary.com/browse/meh#:~:text=unimpressive%3B%20boring%3A>)\u201d or standard.\n\nOut of the 58 in-the-wild 0-days for the year, 39, or 67% were memory corruption vulnerabilities. Memory corruption vulnerabilities have been the standard for attacking software for the last few decades and it\u2019s still how attackers are having success. Out of these memory corruption vulnerabilities, the majority also stuck with very popular and well-known bug classes:\n\n * 17 use-after-free\n * 6 out-of-bounds read & write\n * 4 buffer overflow\n * 4 integer overflow\n\nIn the next sections we\u2019ll dive into each major platform that we saw in-the-wild 0-days for this year. We\u2019ll share the trends and explain why what we saw was pretty unexceptional.\n\n## Chromium (Chrome)\n\nChromium had a record high number of 0-days detected and disclosed in 2021 with 14. Out of these 14, 10 were renderer remote code execution bugs, 2 were sandbox escapes, 1 was an infoleak, and 1 was used to open a webpage in Android apps other than Google Chrome.\n\nThe 14 0-day vulnerabilities were in the following components:\n\n * 6 JavaScript Engine - v8 ([CVE-2021-21148](<https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html>), [CVE-2021-30551](<https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html>), [CVE-2021-30563](<https://chromereleases.googleblog.com/2021/07/stable-channel-update-for-desktop.html>), [CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>), [CVE-2021-37975](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-37975.html>), [CVE-2021-38003](<https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html>))\n * 2 DOM Engine - Blink ([CVE-2021-21193](<https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop_12.html>) & [CVE-2021-21206](<https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop.html>))\n * 1 WebGL ([CVE-2021-30554](<https://chromereleases.googleblog.com/2021/06/stable-channel-update-for-desktop_17.html>))\n * 1 IndexedDB ([CVE-2021-30633](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop.html>))\n * 1 webaudio ([CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>))\n * 1 Portals ([CVE-2021-37973](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop_24.html>))\n * 1 Android Intents ([CVE-2021-38000](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-38000.html>))\n * 1 Core ([CVE-2021-37976](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop_30.html>))\n\nWhen we look at the components targeted by these bugs, they\u2019re all attack surfaces seen before in public security research and previous exploits. If anything, there are a few less DOM bugs and more targeting these other components of browsers like IndexedDB and WebGL than previously. 13 out of the 14 Chromium 0-days were memory corruption bugs. Similar to last year, most of those memory corruption bugs are use-after-free vulnerabilities.\n\nA couple of the Chromium bugs were even similar to previous in-the-wild 0-days. [CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>) is an issue in ScriptProcessorNode::Process() in webaudio where there\u2019s insufficient locks such that buffers are accessible in both the main thread and the audio rendering thread at the same time. [CVE-2019-13720](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2019/CVE-2019-13720.html>) is an in-the-wild 0-day from 2019. It was a vulnerability in ConvolverHandler::Process() in webaudio where there were also insufficient locks such that a buffer was accessible in both the main thread and the audio rendering thread at the same time.\n\n[CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>) is another Chromium in-the-wild 0-day from 2021. It\u2019s a type confusion in the TurboFan JIT in Chromium\u2019s JavaScript Engine, v8, where Turbofan fails to deoptimize code after a property map is changed. [CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>) in particular deals with code that stores global properties. [CVE-2020-16009](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-16009.html>) was also an in-the-wild 0-day that was due to Turbofan failing to deoptimize code after map deprecation.\n\n## WebKit (Safari)\n\nPrior to 2021, Apple had only acknowledged 1 publicly known in-the-wild 0-day targeting WebKit/Safari, and that was due the sharing by an external researcher. In 2021 there were 7. This makes it hard for us to assess trends or changes since we don\u2019t have historical samples to go off of. Instead, we\u2019ll look at 2021\u2019s WebKit bugs in the context of other Safari bugs not known to be in-the-wild and other browser in-the-wild 0-days. \n\nThe 7 in-the-wild 0-days targeted the following components:\n\n * 4 Javascript Engine - JavaScript Core ([CVE-2021-1870](<https://support.apple.com/en-us/HT212146>), [CVE-2021-1871](<https://support.apple.com/en-us/HT212146>), [CVE-2021-30663](<https://support.apple.com/en-us/HT212336>), [CVE-2021-30665](<https://support.apple.com/en-us/HT212336>))\n * 1 IndexedDB ([CVE-2021-30858](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html>))\n * 1 Storage ([CVE-2021-30661](<https://support.apple.com/en-us/HT212317>))\n * 1 Plugins ([CVE-2021-1879](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1879.html>))\n\nThe one semi-surprise is that no DOM bugs were detected and disclosed. In previous years, vulnerabilities in the DOM engine have generally made up 15-20% of the in-the-wild browser 0-days, but none were detected and disclosed for WebKit in 2021. \n\nIt would not be surprising if attackers are beginning to shift to other modules, like third party libraries or things like IndexedDB. The modules may be more promising to attackers going forward because there\u2019s a better chance that the vulnerability may exist in multiple browsers or platforms. For example, the webaudio bug in Chromium, [CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>), also existed in WebKit and was fixed as [CVE-2021-1844](<https://support.apple.com/en-us/HT212223>), though there was no evidence it was exploited in-the-wild in WebKit. The IndexedDB in-the-wild 0-day that was used against Safari in 2021, [CVE-2021-30858](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html>), was very, very similar to a [bug fixed in Chromium in January 2020](<https://bugs.chromium.org/p/chromium/issues/detail?id=1032890>).\n\n## Internet Explorer\n\nSince we began tracking in-the-wild 0-days, Internet Explorer has had a pretty consistent number of 0-days each year. 2021 actually tied 2016 for the most in-the-wild Internet Explorer 0-days we\u2019ve ever tracked even though Internet Explorer\u2019s market share of web browser users continues to decrease.\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbMTlnGhVLcVL8K20S3s6hSrpyB6kZAA9CWvWNpn1isbEbLFv0c2rs_dPvM0ALT45NtTvyhp8rGehGDRIAEJ6OZYSkk5mezOEoPJOquVXXyHeqrVOvRGEiQHv_J7Je8Itjc5qhwXMCR-E4y79abuxiddCYoeF2VrVakY-L1q82NeMEPjTA0fFC-t8h/s1200/image4%286%29.png>)\n\nSo why are we seeing so little change in the number of in-the-wild 0-days despite the change in market share? Internet Explorer is still a ripe attack surface for initial entry into Windows machines, even if the user doesn\u2019t use Internet Explorer as their Internet browser. While the number of 0-days stayed pretty consistent to what we\u2019ve seen in previous years, the components targeted and the delivery methods of the exploits changed. 3 of the 4 0-days seen in 2021 targeted the MSHTML browser engine and were delivered via methods other than the web. Instead they were delivered to targets via Office documents or other file formats. \n\nThe four 0-days targeted the following components:\n\n * MSHTML browser engine ([CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>), [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-33742.html>), [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>))\n * Javascript Engine - JScript9 ([CVE-2021-34448](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34448>))\n\nFor [CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>) targets of the campaign initially received a .mht file, which prompted the user to open in Internet Explorer. Once it was opened in Internet Explorer, the exploit was downloaded and run. [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-33742.html>) and [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>) were delivered to targets via malicious Office documents.\n\n[CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>) and [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-33742.html>) were two common memory corruption bug patterns: a use-after-free due to a user controlled callback in between two actions using an object and the user frees the object during that callback and a buffer overflow.\n\nThere were a few different vulnerabilities used in the exploit chain that used [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>), but the one within MSHTML was that as soon as the Office document was opened the payload would run: a CAB file was downloaded, decompressed, and then a function from within a DLL in that CAB was executed. Unlike the previous two MSHTML bugs, this was a logic error in URL parsing rather than a memory corruption bug.\n\n## Windows\n\nWindows is the platform where we\u2019ve seen the most change in components targeted compared with previous years. However, this shift has generally been in progress for a few years and predicted with the end-of-life of Windows 7 in 2020 and thus why it\u2019s still not especially novel.\n\nIn 2021 there were 10 Windows in-the-wild 0-days targeting 7 different components:\n\n * 2 Enhanced crypto provider ([CVE-2021-31199](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31199>), [CVE-2021-31201](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31201>))\n * 2 NTOS kernel ([CVE-2021-33771](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-33771>), [CVE-2021-31979](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31979>))\n * 2 Win32k ([CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>), [CVE-2021-40449](<https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/>))\n * 1 Windows update medic ([CVE-2021-36948](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36948>)) \n * 1 SuperFetch ([CVE-2021-31955](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31955>))\n * 1 dwmcore.dll ([CVE-2021-28310](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28310>))\n * 1 ntfs.sys ([CVE-2021-31956](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31956>))\n\nThe number of different components targeted is the shift from past years. For example, in 2019 75% of Windows 0-days targeted Win32k while in 2021 Win32k only made up 20% of the Windows 0-days. The reason that this was expected and predicted was that 6 out of 8 of those 0-days that targeted Win32k in 2019 did not target the latest release of Windows 10 at that time; they were targeting older versions. With Windows 10 Microsoft began dedicating more and more resources to locking down the attack surface of Win32k so as those older versions have hit end-of-life, Win32k is a less and less attractive attack surface.\n\nSimilar to the many Win32k vulnerabilities seen over the years, the two 2021 Win32k in-the-wild 0-days are due to custom user callbacks. The user calls functions that change the state of an object during the callback and Win32k does not correctly handle those changes. [CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>) is a type confusion vulnerability due to a user callback in xxxClientAllocWindowClassExtraBytes which leads to out-of-bounds read and write. If NtUserConsoleControl is called during the callback a flag is set in the window structure to signal that a field is an offset into the kernel heap. xxxClientAllocWindowClassExtraBytes doesn\u2019t check this and writes that field as a user-mode pointer without clearing the flag. The first in-the-wild 0-day detected and disclosed in 2022, [CVE-2022-21882](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2022/CVE-2022-21882.html>), is due to [CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>) actually not being fixed completely. The attackers found a way to bypass the original patch and still trigger the vulnerability. [CVE-2021-40449](<https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/>) is a use-after-free in NtGdiResetDC due to the object being freed during the user callback. \n\n## iOS/macOS\n\nAs discussed in the \u201cMore disclosure\u201d section above, 2021 was the first full year that Apple annotated their release notes with in-the-wild status of vulnerabilities. 5 iOS in-the-wild 0-days were detected and disclosed this year. The first publicly known macOS in-the-wild 0-day ([CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>)) was also found. In this section we\u2019re going to discuss iOS and macOS together because: 1) the two operating systems include similar components and 2) the sample size for macOS is very small (just this one vulnerability).\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPGaOlQUGIYyvpDY_M0rGh3JekH4mwXHfN459HYcklg74v4Mfp8j6fgh2SM09mjhA4svdgN_TdSN3R5Bb-DJTHnlo63qnRTsvLs1EZgAE3fBpRtsZhxKhyBNTb_khdS6mNT3EtSHnS_R-TshtHx-gSWnEPpHjmSqO_9Y7JxupGcDKZ0-xwsxgbX6zR/s1200/image6%284%29.png>)\n\nFor the 5 total iOS and macOS in-the-wild 0-days, they targeted 3 different attack surfaces:\n\n * IOMobileFrameBuffer ([CVE-2021-30807](<https://support.apple.com/en-us/HT212623>), [CVE-2021-30883](<https://support.apple.com/en-us/HT212846>))\n * XNU Kernel ([CVE-2021-1782](<https://support.apple.com/en-us/HT212146>) & [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>))\n * CoreGraphics ([CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>))\n * CommCenter ([FORCEDENTRY sandbox escape](<https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html>) \\- CVE requested, not yet assigned)\n\nThese 4 attack surfaces are not novel. IOMobileFrameBuffer has been a target of public security research for many years. For example, the Pangu Jailbreak from 2016 used [CVE-2016-4654](<https://www.blackhat.com/docs/us-16/materials/us-16-Wang-Pangu-9-Internals.pdf>), a heap buffer overflow in IOMobileFrameBuffer. IOMobileFrameBuffer manages the screen\u2019s frame buffer. For iPhone 11 (A13) and below, IOMobileFrameBuffer was a kernel driver. Beginning with A14, it runs on a coprocessor, the DCP. It\u2019s a popular attack surface because historically it\u2019s been accessible from sandboxed apps. In 2021 there were two in-the-wild 0-days in IOMobileFrameBuffer. [CVE-2021-30807](<https://support.apple.com/en-us/HT212623>) is an out-of-bounds read and [CVE-2021-30883](<https://support.apple.com/en-us/HT212846>) is an integer overflow, both common memory corruption vulnerabilities. In 2022, we already have another in-the-wild 0-day in IOMobileFrameBuffer, [CVE-2022-22587](<https://support.apple.com/en-us/HT213053>).\n\nOne iOS 0-day and the macOS 0-day both exploited vulnerabilities in the XNU kernel and both vulnerabilities were in code related to XNU\u2019s inter-process communication (IPC) functionality. [CVE-2021-1782](<https://support.apple.com/en-us/HT212146>) exploited a vulnerability in mach vouchers while [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>) exploited a vulnerability in mach messages. This is not the first time we\u2019ve seen iOS in-the-wild 0-days, much less public security research, targeting mach vouchers and mach messages. [CVE-2019-6625](<https://support.apple.com/en-us/HT209443>) was exploited as a part of [an exploit chain targeting iOS 11.4.1-12.1.2](<https://googleprojectzero.blogspot.com/2019/08/in-wild-ios-exploit-chain-5.html>) and was also a [vulnerability in mach vouchers](<https://googleprojectzero.blogspot.com/2019/01/voucherswap-exploiting-mig-reference.html>). \n\nMach messages have also been a popular target for public security research. In 2020 there were two in-the-wild 0-days also in mach messages: [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>) & [CVE-2020-27950](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27950.html>). This year\u2019s [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>) is a pretty close variant to 2020\u2019s [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>). Tielei Wang and Xinru Chi actually [presented on this vulnerability at zer0con 2021](<https://github.com/wangtielei/Slides/blob/main/zer0con21.pdf>) in April 2021. In their presentation, they explained that they found it while doing variant analysis on [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>). [TieLei Wang explained via Twitter](<https://twitter.com/WangTielei/status/1486266258152726530>) that they had found the vulnerability in December 2020 and had noticed it was fixed in beta versions of iOS 14.4 and macOS 11.2 which is why they presented it at Zer0Con. The in-the-wild exploit only targeted macOS 10, but used the same exploitation technique as the one presented.\n\nThe two FORCEDENTRY exploits ([CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>) and the [sandbox escape](<https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html>)) were the only times that made us all go \u201cwow!\u201d this year. For [CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), the integer overflow in CoreGraphics, it was because: \n\n 1. For years we\u2019ve all heard about how attackers are using 0-click iMessage bugs and finally we have a public example, and\n 2. The exploit was an impressive work of art. \n\nThe sandbox escape (CVE requested, not yet assigned) was impressive because it\u2019s one of the few times we\u2019ve seen a sandbox escape in-the-wild that uses only logic bugs, rather than the standard memory corruption bugs. \n\nFor [CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), the vulnerability itself wasn\u2019t especially notable: a classic integer overflow within the JBIG2 parser of the CoreGraphics PDF decoder. The exploit, though, was described by Samuel Gro\u00df & Ian Beer as \u201cone of the most technically sophisticated exploits [they]\u2019ve ever seen\u201d. [Their blogpost shares all the details](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), but the highlight is that the exploit uses the logical operators available in JBIG2 to build NAND gates which are used to build its own computer architecture. The exploit then writes the rest of its exploit using that new custom architecture. From their blogpost:\n\nUsing over 70,000 segment commands defining logical bit operations, they define a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent.\n\nThe bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It's pretty incredible, and at the same time, pretty terrifying.\n\nThis is an example of what making 0-day exploitation hard could look like: attackers having to develop a new and novel way to exploit a bug and that method requires lots of expertise and/or time to develop. This year, the two FORCEDENTRY exploits were the only 0-days out of the 58 that really impressed us. Hopefully in the future, the bar has been raised such that this will be required for any successful exploitation.\n\n## Android\n\nThere were 7 Android in-the-wild 0-days detected and disclosed this year. Prior to 2021 there had only been 1 and it was in 2019: [CVE-2019-2215](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2019/CVE-2019-2215.html>). Like WebKit, this lack of data makes it hard for us to assess trends and changes. Instead, we\u2019ll compare it to public security research.\n\nFor the 7 Android 0-days they targeted the following components:\n\n * Qualcomm Adreno GPU driver ([CVE-2020-11261](<https://source.android.com/security/bulletin/2021-01-01>), [CVE-2021-1905](<https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-1905.html>), [CVE-2021-1906](<https://source.android.com/security/bulletin/2021-05-01>))\n * ARM Mali GPU driver ([CVE-2021-28663](<https://source.android.com/security/bulletin/2021-05-01>), [CVE-2021-28664](<https://source.android.com/security/bulletin/2021-05-01>))\n * Upstream Linux kernel ([CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>), [CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>))\n\n5 of the 7 0-days from 2021 targeted GPU drivers. This is actually not that surprising when we consider the evolution of the Android ecosystem as well as recent public security research into Android. The Android ecosystem is quite fragmented: many different kernel versions, different manufacturer customizations, etc. If an attacker wants a capability against \u201cAndroid devices\u201d, they generally need to maintain many different exploits to have a decent percentage of the Android ecosystem covered. However, if the attacker chooses to target the GPU kernel driver instead of another component, they will only need to have two exploits since most Android devices use 1 of 2 GPUs: either the Qualcomm Adreno GPU or the ARM Mali GPU. \n\nPublic security research mirrored this choice in the last couple of years as well. When developing full exploit chains (for defensive purposes) to target Android devices, [Guang Gong](<https://github.com/secmob/TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices/blob/master/us-20-Gong-TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices-wp.pdf>), [Man Yue Mo](<https://securitylab.github.com/research/one_day_short_of_a_fullchain_android/>), and [Ben Hawkes](<https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html>) all chose to attack the GPU kernel driver for local privilege escalation. Seeing the in-the-wild 0-days also target the GPU was more of a confirmation rather than a revelation. Of the 5 0-days targeting GPU drivers, 3 were in the Qualcomm Adreno driver and 2 in the ARM Mali driver. \n\nThe two non-GPU driver 0-days ([CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>) and [CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>)) targeted the upstream Linux kernel. Unfortunately, these 2 bugs shared a singular characteristic with the Android in-the-wild 0-day seen in 2019: all 3 were previously known upstream before their exploitation in Android. While the sample size is small, it\u2019s still quite striking to see that 100% of the known in-the-wild Android 0-days that target the kernel are bugs that actually were known about before their exploitation.\n\nThe vulnerability now referred to as [CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>) was actually found in September 2016 and [discussed on the Linux kernel mailing lists](<https://lore.kernel.org/lkml/CAOssrKcfncAYsQWkfLGFgoOxAQJVT2hYVWdBA6Cw7hhO8RJ_wQ@mail.gmail.com/>). A [patch was even developed back in 2016](<https://lore.kernel.org/lkml/1475150954-10152-1-git-send-email-mszeredi@redhat.com/>), but it didn\u2019t end up being submitted. The bug was finally [fixed in the Linux kernel in July 2021](<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cbcf01128d0a92e131bd09f1688fe032480b65ca>) after the detection of the in-the-wild exploit targeting Android. The patch then made it into the [Android security bulletin in November 2021](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>).\n\n[CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>) remained unpatched in Android for 14 months after it was patched in the Linux kernel. The Linux kernel was actually only vulnerable to the issue for a few weeks, but due to Android patching practices, that few weeks became almost a year for some Android devices. If an Android OEM synced to the upstream kernel, then they likely were patched against the vulnerability at some point. But many devices, such as recent Samsung devices, had not and thus were left vulnerable.\n\n## Microsoft Exchange Server\n\nIn 2021, there were 5 in-the-wild 0-days targeting Microsoft Exchange Server. This is the first time any Exchange Server in-the-wild 0-days have been detected and disclosed since we began tracking in-the-wild 0-days. The first four ([CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>), [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>), [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>), and [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>)) were all disclosed and patched at the same time and used together in a [single operation](<https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/>). The fifth ([CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>)) was patched on its own in November 2021. [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>) was demonstrated at Tianfu Cup and then discovered in-the-wild by Microsoft. While no other in-the-wild 0-days were disclosed as part of the chain with [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>), the attackers would have required at least another 0-day for successful exploitation since [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>) is a post-authentication bug.\n\nOf the four Exchange in-the-wild 0-days used in the first campaign, [CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>), which is also known as \u201cProxyLogon\u201d, is the only one that\u2019s pre-auth. [CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>) is a server side request forgery (SSRF) vulnerability that allows unauthenticated attackers to send arbitrary HTTP requests as the Exchange server. The other three vulnerabilities were post-authentication. For example, [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>) and [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>) allowed attackers to write arbitrary files to the system. [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>) is a remote code execution vulnerability due to a deserialization bug in the Unified Messaging service. This allowed attackers to run code as the privileged SYSTEM user.\n\nFor the second campaign, [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>), like [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>), is a post-authentication RCE vulnerability due to insecure deserialization. It seems that while attempting to harden Exchange, Microsoft inadvertently introduced another deserialization vulnerability.\n\nWhile there were a significant amount of 0-days in Exchange detected and disclosed in 2021, it\u2019s important to remember that they were all used as 0-day in only two different campaigns. This is an example of why we don\u2019t suggest using the number of 0-days in a product as a metric to assess the security of a product. Requiring the use of four 0-days for attackers to have success is preferable to an attacker only needing one 0-day to successfully gain access.\n\nWhile this is the first time Exchange in-the-wild 0-days have been detected and disclosed since Project Zero began our tracking, this is not unexpected. In 2020 there was [n-day exploitation of Exchange Servers](<https://www.cisa.gov/uscert/ncas/current-activity/2020/03/10/unpatched-microsoft-exchange-servers-vulnerable-cve-2020-0688>). Whether this was the first year that attackers began the 0-day exploitation or if this was the first year that defenders began detecting the 0-day exploitation, this is not an unexpected evolution and we\u2019ll likely see it continue into 2022.\n\n# Outstanding Questions\n\nWhile there has been progress on detection and disclosure, that progress has shown just how much work there still is to do. The more data we gained, the more questions that arose about biases in detection, what we\u2019re missing and why, and the need for more transparency from both vendors and researchers.\n\nUntil the day that attackers decide to happily share all their exploits with us, we can\u2019t fully know what percentage of 0-days are publicly known about. However when we pull together our expertise as security researchers and anecdotes from others in the industry, it paints a picture of some of the data we\u2019re very likely missing. From that, these are some of the key questions we\u2019re asking ourselves as we move into 2022:\n\n## Where are the [x] 0-days?\n\nDespite the number of 0-days found in 2021, there are key targets missing from the 0-days discovered. For example, we know that messaging applications like WhatsApp, Signal, Telegram, etc. are targets of interest to attackers and yet there\u2019s only 1 messaging app, in this case iMessage, 0-day found this past year. Since we began tracking in mid-2014 the total is two: a WhatsApp 0-day in 2019 and this iMessage 0-day found in 2021.\n\nAlong with messaging apps, there are other platforms/targets we\u2019d expect to see 0-days targeting, yet there are no or very few public examples. For example, since mid-2014 there\u2019s only one in-the-wild 0-day each for macOS and Linux. There are no known in-the-wild 0-days targeting cloud, CPU vulnerabilities, or other phone components such as the WiFi chip or the baseband.\n\nThis leads to the question of whether these 0-days are absent due to lack of detection, lack of disclosure, or both?\n\n## Do some vendors have no known in-the-wild 0-days because they\u2019ve never been found or because they don\u2019t publicly disclose?\n\nUnless a vendor has told us that they will publicly disclose exploitation status for all vulnerabilities in their platforms, we, the public, don\u2019t know if the absence of an annotation means that there is no known exploitation of a vulnerability or if there is, but the vendor is just not sharing that information publicly. Thankfully this question is something that has a pretty clear solution: all device and software vendors agreeing to publicly disclose when there is evidence to suggest that a vulnerability in their product is being exploited in-the-wild.\n\n## Are we seeing the same bug patterns because that\u2019s what we know how to detect?\n\nAs we described earlier in this report, all the 0-days we saw in 2021 had similarities to previously seen vulnerabilities. This leads us to wonder whether or not that\u2019s actually representative of what attackers are using. Are attackers actually having success exclusively using vulnerabilities in bug classes and components that are previously public? Or are we detecting all these 0-days with known bug patterns because that\u2019s what we know how to detect? Public security research would suggest that yes, attackers are still able to have success with using vulnerabilities in known components and bug classes the majority of the time. But we\u2019d still expect to see a few novel and unexpected vulnerabilities in the grouping. We posed this question back in the 2019 year-in-review and it still lingers. \n\n## Where are the spl0itz?\n\nTo successfully exploit a vulnerability there are two key pieces that make up that exploit: the vulnerability being exploited, and the exploitation method (how that vulnerability is turned into something useful). \n\nUnfortunately, this report could only really analyze one of these components: the vulnerability. Out of the 58 0-days, only 5 have an exploit sample publicly available. Discovered in-the-wild 0-days are the failure case for attackers and a key opportunity for defenders to learn what attackers are doing and make it harder, more time-intensive, more costly, to do it again. Yet without the exploit sample or a detailed technical write-up based upon the sample, we can only focus on fixing the vulnerability rather than also mitigating the exploitation method. This means that attackers are able to continue to use their existing exploit methods rather than having to go back to the design and development phase to build a new exploitation method. While acknowledging that sharing exploit samples can be challenging (we have that challenge too!), we hope in 2022 there will be more sharing of exploit samples or detailed technical write-ups so that we can come together to use every possible piece of information to make it harder for the attackers to exploit more users.\n\nAs an aside, if you have an exploit sample that you\u2019re willing to share with us, please reach out. Whether it\u2019s sharing with us and having us write a detailed technical description and analysis or having us share it publicly, we\u2019d be happy to work with you.\n\n# Conclusion\n\nLooking back on 2021, what comes to mind is \u201cbaby steps\u201d. We can see clear industry improvement in the detection and disclosure of 0-day exploits. But the better detection and disclosure has highlighted other opportunities for progress. As an industry we\u2019re not making 0-day hard. Attackers are having success using vulnerabilities similar to what we\u2019ve seen previously and in components that have previously been discussed as attack surfaces.The goal is to force attackers to start from scratch each time we detect one of their exploits: they\u2019re forced to discover a whole new vulnerability, they have to invest the time in learning and analyzing a new attack surface, they must develop a brand new exploitation method. And while we made distinct progress in detection and disclosure it has shown us areas where that can continue to improve.\n\nWhile this all may seem daunting, the promising part is that we\u2019ve done it before: we have made clear progress on previously daunting goals. In 2019, we discussed the large detection deficit for 0-day exploits and 2 years later more than double were detected and disclosed. So while there is still plenty more work to do, it\u2019s a tractable problem. There are concrete steps that the tech and security industries can take to make it even more progress: \n\n\n 1. Make it an industry standard behavior for all vendors to publicly disclose when there is evidence to suggest that a vulnerability in their product is being exploited,\n 2. Vendors and security researchers sharing exploit samples or detailed descriptions of the exploit techniques.\n 3. Continued concerted efforts on reducing memory corruption vulnerabilities or rendering them unexploitable.\n\nThrough 2021 we continually saw the real world impacts of the use of 0-day exploits against users and entities. Amnesty International, the Citizen Lab, and others highlighted [over](<https://citizenlab.ca/2021/10/breaking-news-new-york-times-journalist-ben-hubbard-pegasus/>) and [over](<https://www.amnesty.org/en/documents/doc10/4491/2021/en/>) how governments were using commercial surveillance products against [journalists](<https://forbiddenstories.org/pegasus-the-new-global-weapon-for-silencing-journalists/>), [human rights defenders](<https://www.amnesty.org/en/latest/research/2021/11/devices-of-palestinian-human-rights-defenders-hacked-with-nso-groups-pegasus-spyware-2/>), and [government officials](<https://www.reuters.com/technology/exclusive-us-state-department-phones-hacked-with-israeli-company-spyware-sources-2021-12-03/>). We saw many enterprises scrambling to remediate and protect themselves from the [Exchange Server 0-days](<https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/>). And we even learned of peer [security researchers being targeted by ](<https://blog.google/threat-analysis-group/update-campaign-targeting-security-researchers/>)[North Korean government hackers](<https://blog.google/threat-analysis-group/update-campaign-targeting-security-researchers/>). While the majority of people on the planet do not need to worry about their own personal risk of being targeted with 0-days, 0-day exploitation still affects us all. These 0-days tend to have an outsized impact on society so we need to continue doing whatever we can to make it harder for attackers to be successful in these attacks.\n\n2021 showed us we\u2019re on the right track and making progress, but there\u2019s plenty more to be done to make 0-day hard.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2022-04-19T00:00:00", "type": "googleprojectzero", "title": "\nThe More You Know, The More You Know You Don\u2019t Know\n", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2016-4654", "CVE-2019-13720", "CVE-2019-2215", "CVE-2019-6625", "CVE-2020-0688", "CVE-2020-11261", "CVE-2020-16009", "CVE-2020-27932", "CVE-2020-27950", "CVE-2021-0920", "CVE-2021-1048", "CVE-2021-1732", "CVE-2021-1782", "CVE-2021-1844", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-21148", "CVE-2021-21166", "CVE-2021-21193", "CVE-2021-21206", "CVE-2021-26411", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-28310", "CVE-2021-28663", "CVE-2021-28664", "CVE-2021-30551", "CVE-2021-30554", "CVE-2021-30563", "CVE-2021-30632", "CVE-2021-30633", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30737", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-30883", "CVE-2021-31199", "CVE-2021-31201", "CVE-2021-31955", "CVE-2021-31956", "CVE-2021-31979", "CVE-2021-33742", "CVE-2021-33771", "CVE-2021-34448", "CVE-2021-36948", "CVE-2021-37973", "CVE-2021-37975", "CVE-2021-37976", "CVE-2021-38000", "CVE-2021-38003", "CVE-2021-40444", "CVE-2021-40449", "CVE-2021-41773", "CVE-2021-42321", "CVE-2022-21882", "CVE-2022-22587"], "modified": "2022-04-19T00:00:00", "id": "GOOGLEPROJECTZERO:CA925EE6A931620550EF819815B14156", "href": "https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "qualysblog": [{"lastseen": "2021-11-09T06:36:02", "description": "[Start your VMDR 30-day, no-cost trial today](<https://www.qualys.com/forms/vmdr/>)\n\n## Overview\n\nOn November 3, 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a [Binding Operational Directive 22-01](<https://cyber.dhs.gov/bod/22-01/>), "Reducing the Significant Risk of Known Exploited Vulnerabilities." [This directive](<https://www.cisa.gov/news/2021/11/03/cisa-releases-directive-reducing-significant-risk-known-exploited-vulnerabilities>) recommends urgent and prioritized remediation of the vulnerabilities that adversaries are actively exploiting. It establishes a CISA-managed catalog of known exploited vulnerabilities that carry significant risk to the federal government and establishes requirements for agencies to remediate these vulnerabilities.\n\nThis directive requires agencies to review and update agency internal vulnerability management procedures within 60 days according to this directive and remediate each vulnerability according to the timelines outlined in 'CISA's vulnerability catalog.\n\nQualys helps customers to identify and assess risk to organizations' digital infrastructure and automate remediation. Qualys' guidance for rapid response to Operational Directive is below.\n\n## Directive Scope\n\nThis directive applies to all software and hardware found on federal information systems managed on agency premises or hosted by third parties on an agency's behalf.\n\nHowever, CISA strongly recommends that private businesses and state, local, tribal, and territorial (SLTT) governments prioritize the mitigation of vulnerabilities listed in CISA's public catalog.\n\n## CISA Catalog of Known Exploited Vulnerabilities\n\nIn total, CISA posted a list of [291 Common Vulnerabilities and Exposures (CVEs)](<https://www.cisa.gov/known-exploited-vulnerabilities-catalog>) that pose the highest risk to federal agencies. The Qualys Research team has mapped all these CVEs to applicable QIDs. You can view the complete list of CVEs and the corresponding QIDs [here](<https://success.qualys.com/discussions/s/article/000006791>).\n\n### Not all vulnerabilities are created equal\n\nOur quick review of the 291 CVEs posted by CISA suggests that not all vulnerabilities hold the same priority. CISA has ordered U.S. federal enterprises to apply patches as soon as possible. The remediation guidance can be grouped into three distinct categories:\n\n#### Category 1 \u2013 Past Due\n\nRemediation of 15 CVEs (~5%) are already past due. These vulnerabilities include some of the most significant exploits in the recent past, including PrintNightmare, SigRed, ZeroLogon, and vulnerabilities in CryptoAPI, Pulse Secure, and more. Qualys Patch Management can help you remediate most of these vulnerabilities.\n\n#### Category 2 \u2013 Patch in less than two weeks\n\n100 (34%) Vulnerabilities need to be patched in the next two weeks, or by **November 17, 2022**.\n\n#### Category 3 \u2013 Patch within six months\n\nThe remaining 176 vulnerabilities (60%) must be patched within the next six months or by **May 3, 2022**.\n\n## Detect CISA's Vulnerabilities Using Qualys VMDR\n\nThe Qualys Research team has released several remote and authenticated detections (QIDs) for the vulnerabilities. Since the directive includes 291 CVEs, we recommend executing your search based on vulnerability criticality, release date, or other categories.\n\nFor example, to detect critical CVEs released in 2021:\n\n_vulnerabilities.vulnerability.criticality:CRITICAL and vulnerabilities.vulnerability.cveIds:[ `CVE-2021-1497`,`CVE-2021-1498`,`CVE-2021-1647`,`CVE-2021-1675`,`CVE-2021-1732`,`CVE-2021-1782`,`CVE-2021-1870`,`CVE-2021-1871`,`CVE-2021-1879`,`CVE-2021-1905`,`CVE-2021-1906`,`CVE-2021-20016`,`CVE-2021-21017`,`CVE-2021-21148`,`CVE-2021-21166`,`CVE-2021-21193`,`CVE-2021-21206`,`CVE-2021-21220`,`CVE-2021-21224`,`CVE-2021-21972`,`CVE-2021-21985`,`CVE-2021-22005`,`CVE-2021-22205`,`CVE-2021-22502`,`CVE-2021-22893`,`CVE-2021-22894`,`CVE-2021-22899`,`CVE-2021-22900`,`CVE-2021-22986`,`CVE-2021-26084`,`CVE-2021-26411`,`CVE-2021-26855`,`CVE-2021-26857`,`CVE-2021-26858`,`CVE-2021-27059`,`CVE-2021-27065`,`CVE-2021-27085`,`CVE-2021-27101`,`CVE-2021-27102`,`CVE-2021-27103`,`CVE-2021-27104`,`CVE-2021-28310`,`CVE-2021-28550`,`CVE-2021-28663`,`CVE-2021-28664`,`CVE-2021-30116`,`CVE-2021-30551`,`CVE-2021-30554`,`CVE-2021-30563`,`CVE-2021-30632`,`CVE-2021-30633`,`CVE-2021-30657`,`CVE-2021-30661`,`CVE-2021-30663`,`CVE-2021-30665`,`CVE-2021-30666`,`CVE-2021-30713`,`CVE-2021-30761`,`CVE-2021-30762`,`CVE-2021-30807`,`CVE-2021-30858`,`CVE-2021-30860`,`CVE-2021-30860`,`CVE-2021-30869`,`CVE-2021-31199`,`CVE-2021-31201`,`CVE-2021-31207`,`CVE-2021-31955`,`CVE-2021-31956`,`CVE-2021-31979`,`CVE-2021-33739`,`CVE-2021-33742`,`CVE-2021-33771`,`CVE-2021-34448`,`CVE-2021-34473`,`CVE-2021-34523`,`CVE-2021-34527`,`CVE-2021-35211`,`CVE-2021-36741`,`CVE-2021-36742`,`CVE-2021-36942`,`CVE-2021-36948`,`CVE-2021-36955`,`CVE-2021-37973`,`CVE-2021-37975`,`CVE-2021-37976`,`CVE-2021-38000`,`CVE-2021-38003`,`CVE-2021-38645`,`CVE-2021-38647`,`CVE-2021-38647`,`CVE-2021-38648`,`CVE-2021-38649`,`CVE-2021-40444`,`CVE-2021-40539`,`CVE-2021-41773`,`CVE-2021-42013`,`CVE-2021-42258` ]_\n\n\n\nUsing [Qualys VMDR](<https://www.qualys.com/subscriptions/vmdr/>), you can effectively prioritize those vulnerabilities using the VMDR Prioritization report.\n\n\n\nIn addition, you can locate a vulnerable host through Qualys Threat Protection by simply clicking on the impacted hosts to effectively identify and track this vulnerability.\n\n\n\nWith Qualys Unified Dashboard, you can track your exposure to the CISA Known Exploited Vulnerabilities and gather your status and overall management in real-time. With trending enabled for dashboard widgets, you can keep track of the status of the vulnerabilities in your environment using the ["CISA 2010-21| KNOWN EXPLOITED VULNERABILITIES"](<https://success.qualys.com/support/s/article/000006791>) Dashboard.\n\n### Detailed Operational Dashboard:\n\n\n\n### Summary Dashboard High Level Structured by Vendor:\n\n\n\n## Remediation\n\nTo comply with this directive, federal agencies must remediate most "Category 2" vulnerabilities by **November 17, 2021**, and "Category 3" by May 3, 2021. Qualys Patch Management can help streamline the remediation of many of these vulnerabilities.\n\nCustomers can copy the following query into the Patch Management app to help customers comply with the directive's aggressive remediation date of November 17, 2021. Running this query will find all required patches and allow quick and efficient deployment of those missing patches to all assets directly from within the Qualys Cloud Platform.\n\ncve:[`CVE-2021-1497`,`CVE-2021-1498`,`CVE-2021-1647`,`CVE-2021-1675`,`CVE-2021-1732`,`CVE-2021-1782`,`CVE-2021-1870`,`CVE-2021-1871`,`CVE-2021-1879`,`CVE-2021-1905`,`CVE-2021-1906`,`CVE-2021-20016`,`CVE-2021-21017`,`CVE-2021-21148`,`CVE-2021-21166`,`CVE-2021-21193`,`CVE-2021-21206`,`CVE-2021-21220`,`CVE-2021-21224`,`CVE-2021-21972`,`CVE-2021-21985`,`CVE-2021-22005`,`CVE-2021-22205`,`CVE-2021-22502`,`CVE-2021-22893`,`CVE-2021-22894`,`CVE-2021-22899`,`CVE-2021-22900`,`CVE-2021-22986`,`CVE-2021-26084`,`CVE-2021-26411`,`CVE-2021-26855`,`CVE-2021-26857`,`CVE-2021-26858`,`CVE-2021-27059`,`CVE-2021-27065`,`CVE-2021-27085`,`CVE-2021-27101`,`CVE-2021-27102`,`CVE-2021-27103`,`CVE-2021-27104`,`CVE-2021-28310`,`CVE-2021-28550`,`CVE-2021-28663`,`CVE-2021-28664`,`CVE-2021-30116`,`CVE-2021-30551`,`CVE-2021-30554`,`CVE-2021-30563`,`CVE-2021-30632`,`CVE-2021-30633`,`CVE-2021-30657`,`CVE-2021-30661`,`CVE-2021-30663`,`CVE-2021-30665`,`CVE-2021-30666`,`CVE-2021-30713`,`CVE-2021-30761`,`CVE-2021-30762`,`CVE-2021-30807`,`CVE-2021-30858`,`CVE-2021-30860`,`CVE-2021-30860`,`CVE-2021-30869`,`CVE-2021-31199`,`CVE-2021-31201`,`CVE-2021-31207`,`CVE-2021-31955`,`CVE-2021-31956`,`CVE-2021-31979`,`CVE-2021-33739`,`CVE-2021-33742`,`CVE-2021-33771`,`CVE-2021-34448`,`CVE-2021-34473`,`CVE-2021-34523`,`CVE-2021-34527`,`CVE-2021-35211`,`CVE-2021-36741`,`CVE-2021-36742`,`CVE-2021-36942`,`CVE-2021-36948`,`CVE-2021-36955`,`CVE-2021-37973`,`CVE-2021-37975`,`CVE-2021-37976`,`CVE-2021-38000`,`CVE-2021-38003`,`CVE-2021-38645`,`CVE-2021-38647`,`CVE-2021-38647`,`CVE-2021-38648`,`CVE-2021-38649`,`CVE-2021-40444`,`CVE-2021-40539`,`CVE-2021-41773`,`CVE-2021-42013`,`CVE-2021-42258` ]\n\n\n\nQualys patch content covers many Microsoft, Linux, and third-party applications; however, some of the vulnerabilities introduced by CISA are not currently supported out-of-the-box by Qualys. To remediate those vulnerabilities, Qualys provides the ability to deploy custom patches. The flexibility to customize patch deployment allows customers to patch the remaining CVEs in this list.\n\nNote that the due date for \u201cCategory 1\u201d patches has already passed. To find missing patches in your environment for \u201cCategory 1\u201d past due CVEs, copy the following query into the Patch Management app:\n\ncve:['CVE-2021-1732\u2032,'CVE-2020-1350\u2032,'CVE-2020-1472\u2032,'CVE-2021-26855\u2032,'CVE-2021-26858\u2032,'CVE-2021-27065\u2032,'CVE-2020-0601\u2032,'CVE-2021-26857\u2032,'CVE-2021-22893\u2032,'CVE-2020-8243\u2032,'CVE-2021-22900\u2032,'CVE-2021-22894\u2032,'CVE-2020-8260\u2032,'CVE-2021-22899\u2032,'CVE-2019-11510']\n\n\n\n## Federal Enterprises and Agencies Can Act Now\n\nFor federal enterprises and agencies, it's a race against time to remediate these vulnerabilities across their respective environments and achieve compliance with this binding directive. Qualys solutions can help achieve compliance with this binding directive. Qualys Cloud Platform is FedRAMP authorized, with [107 FedRAMP authorizations](<https://marketplace.fedramp.gov/#!/product/qualys-cloud-platform?sort=-authorizations>).\n\nHere are a few steps Federal enterprises can take immediately:\n\n * Run vulnerability assessments against all your assets by leveraging various sensors such as Qualys agent, scanners, and more\n * Prioritize remediation by due dates\n * Identify all vulnerable assets automatically mapped into the threat feed\n * Use Patch Management to apply patches and other configurations changes\n * Track remediation progress through Unified Dashboards\n\n## Summary\n\nUnderstanding vulnerabilities is a critical but partial part of threat mitigation. Qualys VMDR helps customers discover, assess threats, assign risk, and remediate threats in one solution. Qualys customers rely on the accuracy of Qualys' threat intelligence to protect their digital environments and stay current with patch guidance. Using Qualys VMDR can help any organization efficiently respond to the CISA directive.\n\n## Getting Started\n\nLearn how [Qualys VMDR](<https://www.qualys.com/subscriptions/vmdr/>) provides actionable vulnerability guidance and automates remediation in one solution. Ready to get started? Sign up for a 30-day, no-cost [VMDR trial](<https://www.qualys.com/forms/vmdr/>).", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 10.0, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 6.0}, "published": "2021-11-09T06:15:01", "type": "qualysblog", "title": "Qualys Response to CISA Alert: Binding Operational Directive 22-01", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-11510", "CVE-2020-0601", "CVE-2020-1350", "CVE-2020-1472", "CVE-2020-8243", "CVE-2020-8260", "CVE-2021-1497", "CVE-2021-1498", "CVE-2021-1647", "CVE-2021-1675", "CVE-2021-1732", "CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-20016", "CVE-2021-21017", "CVE-2021-21148", "CVE-2021-21166", "CVE-2021-21193", "CVE-2021-21206", "CVE-2021-21220", "CVE-2021-21224", "CVE-2021-21972", "CVE-2021-21985", "CVE-2021-22005", "CVE-2021-22205", "CVE-2021-22502", "CVE-2021-22893", "CVE-2021-22894", "CVE-2021-22899", "CVE-2021-22900", "CVE-2021-22986", "CVE-2021-26084", "CVE-2021-26411", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27059", "CVE-2021-27065", "CVE-2021-27085", "CVE-2021-27101", "CVE-2021-27102", "CVE-2021-27103", "CVE-2021-27104", "CVE-2021-28310", "CVE-2021-28550", "CVE-2021-28663", "CVE-2021-28664", "CVE-2021-30116", "CVE-2021-30551", "CVE-2021-30554", "CVE-2021-30563", "CVE-2021-30632", "CVE-2021-30633", "CVE-2021-30657", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666", "CVE-2021-30713", "CVE-2021-30761", "CVE-2021-30762", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-31199", "CVE-2021-31201", "CVE-2021-31207", "CVE-2021-31955", "CVE-2021-31956", "CVE-2021-31979", "CVE-2021-33739", "CVE-2021-33742", "CVE-2021-33771", "CVE-2021-34448", "CVE-2021-34473", "CVE-2021-34523", "CVE-2021-34527", "CVE-2021-35211", "CVE-2021-36741", "CVE-2021-36742", "CVE-2021-36942", "CVE-2021-36948", "CVE-2021-36955", "CVE-2021-37973", "CVE-2021-37975", "CVE-2021-37976", "CVE-2021-38000", "CVE-2021-38003", "CVE-2021-38645", "CVE-2021-38647", "CVE-2021-38648", "CVE-2021-38649", "CVE-2021-40444", "CVE-2021-40539", "CVE-2021-41773", "CVE-2021-42013", "CVE-2021-42258"], "modified": "2021-11-09T06:15:01", "id": "QUALYSBLOG:BC22CE22A3E70823D5F0E944CBD5CE4A", "href": "https://blog.qualys.com/category/vulnerabilities-threat-research", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}]}
CVE-2021-1905
