Very High
CVE-2020-6418
Add Reference
Description
URL
Type
Very High
(4 users assessed)
Low
(4 users assessed)Required
None
Network
CVE-2020-6418
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
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
Ratings
-
Attacker ValueHigh
-
ExploitabilityVery 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.
Ratings
-
Attacker ValueHigh
-
ExploitabilityMedium
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.
Ratings
-
Attacker ValueVery High
-
ExploitabilityVery 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:
- https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping/
- https://github.com/ray-cp/browser_pwn/tree/master/cve-2020-6418
Edited: To correct upper version number
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
General Information
Vendors
Products
- Chrome
References
Advisory
Additional Info
Technical Analysis
Report as Exploited in the Wild
What do we mean by "exploited in the wild"?
By selecting this, you are verifying to the AttackerKB community that either you, or a reputable source (example: a security vendor or researcher), has observed an active attempt by attackers, or IOCs related, to exploit this vulnerability outside of a research environment.
A vulnerability should also be considered "exploited in the wild" if there is a publicly available PoC or exploit (example: in an exploitation framework like Metasploit).
