ZeroHour

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2020-1020
+2 in the same advisory: …0938 …1027
Out-of-Bounds Write RCE in Microsoft Windows Adobe Font Manager Library

CVE-2020-1020 is a remote code execution vulnerability (out-of-bounds write, CWE-787) in the Adobe Font Manager Library shipped with Microsoft Windows, caused by improper handling of a specially crafted multi-master font in Adobe Type 1 PostScript format. Triggering it requires user interaction: an attacker delivers a malicious document or font, and the vulnerable code runs when the content is previewed or opened (no authentication is needed on the network path, but the user must interact). On all systems except Windows 10, successful exploitation allows the attacker to execute arbitrary code remotely in the context of the current user; on Windows 10 the flaw is present as well, with the full remote-code-execution impact described for non-Windows-10 systems. Affected software spans Windows 10 versions 1507 through 1909, Windows 7, Windows 8.1, Windows RT 8.1, and Windows Server 1903/1909. The bug was exploited in the wild as a zero-day by a sophisticated threat actor prior to patching (CISA KEV, added 2021-11-03), and EPSS assigns a 65% probability of exploitation within 30 days (99th percentile).

Do: Apply Microsoft's security update for CVE-2020-1020 via Windows Update (April 2020 Patch Tuesday cycle) on all Windows 7, 8.1, RT 8.1, Windows 10 1507-1909, and Windows Server 1903/1909 hosts, per CISA's required action. As interim mitigation, disable the Explorer preview and details panes and avoid opening or previewing untrusted documents and fonts. Verify the fix is deployed, prioritizing non-Windows-10 systems where successful exploitation yields full remote code execution.

8.8
group max
65% KEV
  • microsoft Windows 10 1507, 1607, 1709, 1803, 1809, 1903, 1909
  • microsoft Windows 7
  • microsoft Windows 8.1
  • +3 more
masshundreds of millions of Windows client/server devices (OS component shipped in all listed Windows releases)
CVE-2020-15999
Heap Buffer Overflow in FreeType Font Rendering in Google Chrome (CVE-2020-15999)

Google Chrome bundles the open-source FreeType library for font rendering, and that library contains a heap buffer overflow (CWE-787, out-of-bounds write) in its Load_SBit_Png function. The flaw is triggered when the browser loads a crafted font containing a malicious PNG image embedded as embedded bitmap data, typically from a web page the victim visits, corrupting heap memory with attacker-controlled data. Successful exploitation can crash the browser or execute code in the renderer, and it was used in the wild as part of an exploit chain combined with CVE-2020-17087 (Windows kernel) and CVE-2020-16010 (Android) to escape the sandbox. Anyone running an affected Google Chrome release that ships the vulnerable FreeType code, across Windows, macOS, Linux, Chrome OS and Android, is affected, meaning effectively the entire Chrome install base at the time of disclosure. The vulnerability is confirmed exploited in the wild (listed in CISA's KEV catalog, added 2021-11-03; ransomware use unknown), Google patched it in Chrome 86.0.4240.111, no public proof-of-concept is known, and EPSS estimates a 44.3% probability of exploitation within 30 days (99th percentile).

Do: Update Google Chrome to 86.0.4240.111 or later (any current stable-channel release satisfies this), and where other software bundles FreeType directly, update to FreeType 2.10.4 or later per the upstream fix. Because the bug was chained with CVE-2020-17087 on Windows and CVE-2020-16010 on Android, also apply the corresponding Microsoft Windows and Android updates to close the sandbox-escape chain. Use endpoint management to inventory browser versions and confirm no endpoints remain below the fixed release, as required by the CISA KEV catalog.

9.644% KEV PoC ×2
  • Google Chrome (bundled FreeType font rendering library) Chrome releases prior to 86.0.4240.111 (the release containing the FreeType fix); standalone FreeType builds prior to 2.10.4
masson the order of billions of users (Chrome's active user base exceeded ~3 billion at the time; the vulnerable FreeType code shipped in every affected release)
CVE-2020-16009
Type Confusion in Google Chromium V8 Engine Enables RCE via Crafted HTML Pages

CVE-2020-16009 is a type confusion vulnerability (CWE-843) in the V8 JavaScript engine used by Google Chromium, which can lead to heap corruption (CWE-787). A remote attacker triggers it by getting a user to load a specially crafted HTML page, such as via a malicious or compromised website. Successful exploitation corrupts the heap and can potentially allow the attacker to execute code in the context of the affected browser. Any Chromium-based browser or application embedding V8 is affected, including Google Chrome, Microsoft Edge, and Opera, meaning the affected population is effectively the entire Chromium user base worldwide. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2021-11-03, confirming exploitation in the wild, with an EPSS probability of 48.3% (99th percentile); ransomware use is unknown and no public PoC is known.

Do: Apply the vendor update per CISA's required action: update all Chromium-based browsers (Chrome, Edge, Opera, and derivatives) to the latest stable releases from each vendor and restart browsers afterward. Inventory any embedded or packaged Chromium/V8 runtimes in other applications and update them as their maintainers ship fixes. Given confirmed in-the-wild exploitation and high EPSS, prioritize patching endpoints used for web browsing by high-risk users first.

8.848% KEV PoC ×2
  • Google Chromium V8
  • Google Chrome (Chromium-based browser)
  • Microsoft Edge (Chromium-based browser)
  • +1 more
mass≈3+ billion browser users/installations (Chromium is the world's dominant browser engine)
CVE-2020-16010
Heap Buffer Overflow in Google Chrome for Android Enables Sandbox Escape

CVE-2020-16010 is a heap buffer overflow (out-of-bounds write, CWE-787/CWE-122) in the UI layer of Google Chrome on Android, fixed in version 86.0.4240.185. It is triggered by a crafted HTML page after a remote attacker has already compromised the Chrome renderer process, meaning it typically functions as a second-stage component of an exploit chain. Successful exploitation lets the attacker escape Chrome's sandbox, moving from the isolated renderer to broader access on the device, with confidentiality, integrity, and availability all rated high (CVSS 3.1: 9.6). Users running Chrome on Android prior to 86.0.4240.185 are affected. The flaw is confirmed exploited in the wild — it was added to CISA's Known Exploited Vulnerabilities catalog on 2021-11-03 — and EPSS assigns a 6.4% probability of exploitation in the next 30 days (93rd percentile).

Do: Update Chrome on Android to 86.0.4240.185 or later via Google Play and confirm the version on the device (chrome://version); given the CISA KEV listing, treat this patch as urgent. Because the bug requires a prior renderer compromise, also ensure the device's Chrome build includes all current renderer fixes, and enable Play Store auto-updates on managed fleets.

9.66% KEV
  • Google Chrome for Android prior to 86.0.4240.185
mass≈1–3 billion users (Chrome for Android has billions of installs and ships as the default browser on most Android devices)
CVE-2020-17087
Windows Kernel Buffer Overflow Enables Local Privilege Escalation (CVE-2020-17087)

CVE-2020-17087 is a local elevation-of-privilege flaw in the Windows kernel caused by an incorrect buffer size calculation (CWE-131), producing a kernel buffer overflow; public analyses from Microsoft and Google's disclosure place the vulnerable code in the kernel's cryptographic driver (cng.sys). A local attacker with low privileges can trigger the overflow without user interaction, gaining code execution in kernel context and effectively full control of the host (high impact on confidentiality, integrity, and availability; CVSS 7.8). Every Windows system on the affected builds is exposed: Windows 10 versions 1507 through 20H2, Windows 7, 8.1, RT 8.1, and Windows Server 2008, which at disclosure meant essentially the entire supported Windows install base. The flaw was exploited as a zero-day in the wild: Google disclosed its use in targeted attacks, reportedly chained with a Chrome zero-day, and CISA added it to the KEV catalog on 2021-11-03; EPSS currently estimates a 5.4% probability of exploitation within 30 days (92nd percentile), with ransomware association listed as unknown.

Do: Apply Microsoft's November 2020 Patch Tuesday security updates to all affected Windows 10, Windows 7, 8.1, RT 8.1, and Windows Server 2008 systems; this is CISA's required action for the KEV listing and no official workaround is known. Prioritize hosts where untrusted users can log on locally or via RDP, and ensure Chromium-based browsers are fully updated since this kernel bug was reportedly chained with a Chrome zero-day. After patching, verify the November 2020 update is installed; treat any ransomware association as currently unconfirmed.

7.85% KEV
  • microsoft Windows 10 1507, 1607, 1803, 1809, 1903, 1909, 2004, 20H2
  • microsoft Windows 7
  • microsoft Windows 8.1
  • +2 more
mass≈1 billion+ devices (essentially the entire supported Windows install base at disclosure)
CVE-2020-27930
+2 in the same advisory: …27932 …27950
Out-of-bounds write in Apple FontParser enables code execution on iOS, macOS, watchOS

CVE-2020-27930 is an out-of-bounds write (CWE-787) memory corruption flaw in the FontParser component used by Apple iOS, iPadOS, macOS, and watchOS. It is triggered when an application processes a maliciously crafted font, a file type commonly delivered remotely via web pages, email, documents, or messaging attachments. An attacker who successfully exploits it may achieve arbitrary code execution in the context of the application parsing the font. Any user of the affected Apple platforms running an unpatched OS version is potentially exposed, because font parsing is a core, remotely reachable code path. The flaw is listed in CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03), indicating confirmed exploitation in the wild; no public proof-of-concept is known, CVSS is not yet scored, and EPSS ranks it in the 98th percentile with a 22% probability of exploitation within 30 days.

Do: Apply Apple's OS updates for iOS, iPadOS, macOS, and watchOS that remediate CVE-2020-27930 per vendor instructions, prioritizing devices that render untrusted content and user workstations; as a KEV entry, federal agencies must patch by the catalog deadline. Until patched, reduce exposure by treating untrusted fonts as attack surface (avoid opening suspicious documents/attachments and remote content) and verify OS versions across your fleet with device management tooling.

7.8
group max
22% KEV
  • Apple iOS (FontParser component)
  • Apple iPadOS (FontParser component)
  • Apple macOS (FontParser component)
  • +1 more
masshundreds of millions to 1B+ unpatched Apple devices (vendor's active installed base exceeds 1 billion devices)
CVE-2020-6418
Type Confusion in Google Chrome's V8 Engine Enables Heap Corruption

CVE-2020-6418 is a type confusion vulnerability (CWE-843) in V8, the JavaScript engine used in Google Chrome and Chromium, affecting versions prior to 80.0.3987.122. A remote attacker triggers it by persuading a user to open a crafted HTML page whose JavaScript causes V8 to mishandle object types (public PoCs reference a JSCreate side-effect issue), potentially leading to heap corruption. Successful exploitation can yield arbitrary code execution in the browser, a common stepping stone for further compromise on the victim's system. Any Chrome/Chromium deployment with the vulnerable V8 was affected, including Chromium packages shipped by Fedora, Red Hat Enterprise Linux, and Debian. The flaw was a zero-day exploited in the wild when patched in February 2020; it is listed in CISA KEV (added 2021-11-03) and carries a very high EPSS of 78.8%, making it a priority patch.

Do: Update Google Chrome to 80.0.3987.122 or later and confirm the running version via chrome://settings/help or chrome://version. Apply the updated Chromium packages from Fedora, Red Hat, and Debian on managed Linux endpoints and check whether any hosts still run pre-fix Chromium. Given the KEV listing and 78.8% EPSS, treat patching as urgent; as an interim mitigation on unpatched systems, limit untrusted web browsing or restrict JavaScript from untrusted sites.

8.879% KEV PoC ×2
  • Google Chrome prior to 80.0.3987.122
  • Google Chromium V8 (JavaScript engine component) prior to the fix delivered in Chrome 80.0.3987.122
  • Fedora Project Fedora (Chromium package) Chromium builds with vulnerable V8; distro-specific version numbers not provided in source data
  • +4 more
massbillions of users/installations (Chrome's global install base runs to billions, and at disclosure in February 2020 every Chrome user on a pre-80.0.3987.122…
Full article678 words · extracted from securityaffairs.com · click to collapse

A hacking group has employed at least 11 zero-day flaws as part of an operation that took place in 2020 and targeted Android, iOS, and Windows users.

Google’s Project Zero security team published a report about the activity of a mysterious hacking group that operated over the course of 2020 and exploited at least 11 zero-day vulnerabilities in its attacks on Android, iOS, and Windows users.

Google researchers observed two separate waves of attacks that took place in February and October 2020, respectively. Threat actors set up malicious sites in a series of watering hole attacks that were redirecting visitors to exploit servers hosting exploit chains for Android, Windows, and iOS devices.

“In October 2020, Google Project Zero discovered seven 0-day exploits being actively used in-the-wild. These exploits were delivered via “watering hole” attacks in a handful of websites pointing to two exploit servers that hosted exploit chains for Android, Windows, and iOS devices.” wrote the popular Project Zero researcher Maddie Stone. “These attacks appear to be the next iteration of the campaign discovered in February 2020 and documented in this blog post series.”

In Oct 2020, we discovered seven 0-day exploits in-the-wild from two exploit servers. The exploit chains targeted Android, Windows, and iOS devices.

Each step we take towards making 0-day hard, makes all of us safer.https://t.co/YLosCIuevf

— Maddie Stone (@maddiestone) March 18, 2021

Since February 2020, the same hacking group set up at least a couple dozen websites in its attacks, experts noticed that the threat actors relied on both zero-day vulnerabilities and known flaws.

Nonetheless, the threat actor behind the attacks also showed the ability to replace zero-days on the fly once one was detected and patched by software vendors.

Below the exploits that were delivered based on the device and browser in the last wave of attacks:

Exploit ServerPlatformBrowserRenderer RCESandbox EscapeLocal Privilege Escalation
1iOSSafariStack R/W via Type 1 Fonts (CVE-2020-27930)Not neededInfo leak via mach message trailers (CVE-2020-27950)Type confusion with turnstiles (CVE-2020-27932)
1WindowsChromeFreetype heap buffer overflow(CVE-2020-15999)Not neededcng.sys heap buffer overflow (CVE-2020-17087)
1Android** Note: This was only delivered after #2 went down and CVE-2020-15999 was patched.ChromeV8 type confusion in TurboFan (CVE-2020-16009)UnknownUnknown
2AndroidChromeFreetype heap buffer overflow(CVE-2020-15999)Chrome for Android head buffer overflow (CVE-2020-16010)Unknown
2AndroidSamsung BrowserFreetype heap buffer overflow(CVE-2020-15999)Chromium n-dayUnknown

Below the list of zero-day flaws exploited in the February 2020 campaign:

while the zero-day flaws exploited in the October 2020 attacks are:

At the time of this writing, Google has yet to attribute these campaigns to any specific threat actor and it is still unclear if the attacks have been conducted by a nation-state actor.

“The vulnerabilities cover a fairly broad spectrum of issues – from a modern JIT vulnerability to a large cache of font bugs. Overall each of the exploits themselves showed an expert understanding of exploit development and the vulnerability being exploited. In the case of the Chrome Freetype 0-day, the exploitation method was novel to Project Zero.” concludes the post. “Project Zero closed out 2020 with lots of long days analyzing lots of 0-day exploit chains and seven 0-day exploits. When combined with their earlier 2020 operation, the actor used at least 11 0-days in less than a year.”

If you want to receive the weekly Security Affairs Newsletter for free subscribe here.

Follow me on Twitter: @securityaffairs and Facebook

[adrotate banner=”9″][adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – hacking, zero-day)

[adrotate banner=”5″]

[adrotate banner=”13″]



Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/115786/hacking/11-zero-day-flaws-hacking-group.html