Attacker Value
Very High
(4 users assessed)
Exploitability
Low
(4 users assessed)
User Interaction
Required
Privileges Required
None
Attack Vector
Network
3

CVE-2020-6418

Disclosure Date: February 27, 2020
Exploited in the Wild
Add MITRE ATT&CK tactics and techniques that apply to this CVE.

Description

Type confusion in V8 in Google Chrome prior to 80.0.3987.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

Add Assessment

4
Ratings
  • Attacker Value
    High
  • Exploitability
    Very Low
Technical Analysis

You would have to chain this vulnerability with a working sandbox escape in order to get full value. While there are no doubt working sandbox escapes, this is only one piece of the exploit chain that is necessary to get a reliable foothold on a machine.

Often times there are full chain exploits published which include the code exec, sandbox escape, and a valid privesc but I have been unable to find a full chain for this exploit.

For the average attacker, this hill would be too high to climb to make this useful.

1
Ratings
Technical Analysis

This is a decent vulnerability that was found by István Kurucsai and Vignesh S Rao of Exodus Intelligence and was detailed at https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping/. Metasploit now has a fully working exploit for this vulnerability that grants RCE provided a user browses to an attacker controlled web page. However, as it stands the current module requires the sandbox to be disabled for its shellcode to work properly (see https://github.com/rapid7/metasploit-framework/pull/13008).

Overall its likely that most people will be automatically updating this vulnerabilty, however I will note that it is theoretically possible to make this bug easier to exploit by targeting older versions of the Windows OS such as Windows 7 and prior whereby exploiting a win32k bug may allow the attacker to go from running inside the Chrome render process to running as SYSTEM within the context of the Windows kernel. This is something that has been done in the past (see https://blog.exodusintel.com/2019/05/17/windows-within-windows/ for an example).

Note however that since newer versions of the Windows operating system introduced win32k system call filtering, which Chrome takes advantage of, unless an attacker has a vulnerability in some other core component accessible from the Chrome sandbox they wouldn’t be able to exploit this vulnerability. Whilst vulns still do exist, the reduction in the attack surface (since win32k is a primary source of privilege elevation vulnerabilities) does make this particular vulnerability a lot harder to exploit on modern Windows systems, however it may pose a higher threat for those organizations who are still running legacy systems in their environment.

Overall not a bad bug but unless paired with a sandbox escape bug on an older system, chances are that most people will either be up to date, or running on a system that limits their attack surface. Main target will likely be those running legacy systems were software updates aren’t as easily applied and/or as regular.

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very Low
Technical Analysis

This is an RCE in the Chrome Javascript engine. There are Proof of Concepts that target both Linux and Windows environments.

The existing POCs are not chained with a Sandbox escape which makes successful exploitation just using the existing code impractical.

The Current CVE lists any version of Chrome below 80.0.3987.122 as vulnerable during testing the existing POC would not exploit on versions below 80. This is likely to do with the way the exploit is constructed to target the specific test environment rather than older versions not being vulnerable.

From an attacker perspective, if this exploit could be chained with a sandbox escape it could be very valuable for Watering Hole attacks.

Google Chromes automated update system should protect most users, however, Organisations with version pinned installations may be at a higher risk.

Resources:

Edited: To correct upper version number

1
Technical Analysis

Quick update to my previous analysis but this has now been reported as being exploited in the wild. Just goes to show that public research does help level the playing ground a bit since otherwise this bug would have likely been exploited privately without people knowing about it; early announcement gave people time to patch before this exploit started making the rounds.

See Google’s 2020 0day vulnerability spreadsheet they made available at https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786 for proof of this being listed as exploited in the wild. The original tweet announcing this spreadsheet with the 2020 findings can be found at https://twitter.com/maddiestone/status/1329837665378725888

CVSS V3 Severity and Metrics
Base Score:
8.8 High
Impact Score:
5.9
Exploitability Score:
2.8
Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Attack Vector (AV):
Network
Attack Complexity (AC):
Low
Privileges Required (PR):
None
User Interaction (UI):
Required
Scope (S):
Unchanged
Confidentiality (C):
High
Integrity (I):
High
Availability (A):
High

General Information

Vendors

  • debian,
  • fedoraproject,
  • google,
  • redhat

Products

  • chrome,
  • debian linux 10.0,
  • debian linux 9.0,
  • enterprise linux desktop 6.0,
  • enterprise linux server 6.0,
  • enterprise linux workstation 6.0,
  • fedora 30,
  • fedora 31

Exploited in the Wild

Reported by:
Technical Analysis