CVE-2020-6418

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.

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.

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

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