Remediating the CVE-2024-0517 Vulnerability in Google Chrome

CVE-2024-0517 is an out-of-bounds write vulnerability in the V8 JavaScript engine of Google Chrome prior to version 120.0.6099.224, which allows remote attackers to exploit heap corruption via a crafted HTML page. The vulnerability was first reported by Toan (Suto) Pham of Qrious Secure. 

Attackers can host a website containing a crafted HTML page and trick users into accessing it through phishing emails or social networks. When users visit the site using a vulnerable version of Google Chrome, the embedded malicious code will execute arbitrary commands. 

Attackers can host a website containing a crafted HTML page and trick users into accessing it through phishing emails or social networks. When users visit the site using a vulnerable version of Google Chrome, the embedded malicious code will execute arbitrary commands. 

Maglev, an optimizing compiler in V8, enhances code execution and memory allocation. Maglev runs only when code is executed frequently and marked as "hot," indicating the need for faster execution through compilation rather than slower line-by-line interpretation. 

Typically, allocations occur in non-contiguous memory regions, leading to sparse and inefficient memory use. To address this, V8 employs a technique called folded allocation, which allocates multiple variables continuously and simultaneously. Maglev also optimizes allocations by using folded allocation in its progress. 

To clean up unused memory regions, V8 employs a generational garbage collection (GC) technique, dividing memory into two spaces: the young generation and the old generation. Additionally, there are two garbage collectors: the minor garbage collector, which is responsible for cleaning up the young space, and the major garbage collector, which handles the cleanup of the old space. The young generation is the area of memory where newly created objects are initially allocated and the old generation is a region of memory where long-lived objects are stored. Objects that have survived multiple minor GC cycles in the young generation are eventually promoted to the old generation. 

The vulnerability arises when an object is created from a class inherited from a base class with no explicitly defined constructor (base default constructor), and another object is subsequently created. Due to folded allocation, the allocation of the first object may be followed by the allocation of the second object. If an event such as garbage collection occurs between these two allocations, a type confusion vulnerability can arise.

OPSWAT Graduate Fellows conducted a detailed analysis of the V8 workflow during the allocation process and determined that the following functions are invoked during this process: 

To exploit this vulnerability, OPSWAT Graduate Fellows created WebAssembly instances containing shellcode and attempted to trigger type confusion by GC to control the memory and execute the shellcode: 

During initialization, we first define an array (_arrayObject) containing empty objects. Next, we construct an instance of the child class as well as a trigger garbage collector. Finally, we define another array with a floating-point number, named _arrayDouble. 

After successfully triggering type confusion, executing the shellcode requires reading the memory and overwriting memory at a controlled address. To do this, we created read and write primitives. Exploitation primitives will take advantage of the metadata in the objects to give us arbitrary read/write memory regions and use that to run arbitrary code. 

Next, we created two WebAssembly instances: one for storing the shellcode and another for triggering it. To avoid directly writing shellcode into WebAssembly instance’s memory via read and write primitives, we define some floating-point constant values within the WebAssembly instance. 

Using read and write primitives; we adjust the jump table pointer of the second WebAssembly instance to skip some bytes of the compiled code of constants in the first WebAssembly instance so that the floating-point constants will be interpreted as our intended shellcode:

Finally, after triggering type confusion and using read/write primitives to control the jump table pointers of the WebAssembly instances, we invoked the exported function of the second WebAssembly instance, which causes the shellcode in the first WebAssembly instance to be executed. 

The shellcode we are using is designed to terminate all processes on a Linux machine, as by the following command: 

To simulate this exploitation in a real-world scenario, OPSWAT Graduate Fellows created a maliciously crafted HTML page. 

MetaDefender Endpoint™ was employed to proactively mitigate this CVE by leveraging its "Vulnerable Application" capability. The solution effectively pinpoints and displays all associated CVEs for Google Chrome applications within the endpoint environment. To neutralize the threat, users can promptly uninstall Chrome or apply the latest security patch. By implementing either countermeasure, the CVE is fully contained, significantly reducing the risk of a successful cyberattack on the endpoint.

Discover why organizations, institutions, and entities around the world trust MetaDefender Endpoint to protect critical endpoints. Talk to an expert today to learn more and see for yourself with a free demo.