Bugs in Chrome’s JavaScript engine can lead to powerful exploits. This project aims to stop them

Reading Time: 1 Minute

JavaScript makes the web go around and Google has had to patch multiple zero-day or previously unknown flaws in Chrome’s V8 JavaScript engine this year. In April, Google admitted a high severity bug in V8 tracked as CVE-2021-21224 was being exploited in the wild. 

Chrome has over two billion users, so when zero-day exploits strike Chrome, it’s a big deal. V8, an open source Google project, is a powerful JavaScript engine for Chrome that’s helped advance the web and web applications. V8 also powers the server-side runtime Node.js.    

Now Samuel Groß, a member of the Google Project Zero security researchers team, has detailed a V8 sandbox proposal to help protect its memory from nastier bugs in the engine using virtual machine and sandboxing technologies. 

“V8 bugs typically allow for the construction of unusually powerful exploits. Furthermore, these bugs are unlikely to be mitigated by memory safe languages or upcoming hardware-assisted security features such as MTE or CFI,” explains Groß, referring to security technologies like Microsoft’s Control-flow integrity (CFI) and Intel’s control-flow enforcement technologies (CET). 

” As a result, V8 is especially attractive for real-world attackers.”

See Also: Hackers used never-before-seen wiper in recent attack on Iranian train system

Groß’s comments suggest that even adopting a memory-safe language like Rust — which Google has adopted for new Android code — wouldn’t immediately solve the security problems faced by V8, which is written in C++.  

He also outlines the broad design objectives but, signaling the size of the project, stresses that this sandbox project is in its infancy and that there are some big hurdles to overcome. But V8 is a Google-led open source project and given that V8 has been the source of security vulnerabilities in Chrome, there is a chance that member of GPZ’s proposal could make it across the line.

The issues affect how browser software interacts with hardware beyond the operating system and aims to prevent future flaws in V8 from corrupting a computer’s memory outside of the V8 heap. This would allow an attacker to execute malicious code. 

See Also: Offensive Security Tool: Ruler

One consideration for the additional security protections for V8 is the impact on hardware performance. Groß estimates his proposal would cause an overhead of about “1% overall on real-world workloads”. 

Groß explains the problem with V8 that stems from JIT compilers that can be used trick a machine into emitting machine code that corrupts memory at runtime. 

“Many V8 vulnerabilities exploited by real-world attackers are effectively 2nd order vulnerabilities: the root-cause is often a logic issue in one of the JIT compilers, which can then be exploited to generate vulnerable machine code (e.g. code that is missing a runtime safety check). The generated code can then in turn be exploited to cause memory corruption at runtime.”

See Also: Hacking Stories: Andrian Lamo – The ‘homeless’ Hacker

He also highlights the shortcomings of the latest security technologies, including hardware-based mitigations, that will make V8 an attractive target for years to come and hence is why V8 may need a sandbox approach. These include:

• The attacker has a great amount of control over the memory corruption primitive and can often turn these bugs into highly reliable and fast exploits
• Memory safe languages will not protect from these issues as they are fundamentally logic bugs
• Due to CPU side-channels and the potency of V8 vulnerabilities, upcoming hardware security features such as memory tagging will likely be bypassable most of the time

Despite downplaying the likelihood of the new V8 sandbox actually being adopted, the researcher seems upbeat about its prospects for doing its intended job by requiring an attacker chain together two separate vulnerabilities in order to execute code of their choice. 

“With this sandbox, attackers are assumed to be able to corrupt memory inside the virtual memory cage arbitrarily and from multiple threads, and will now require an additional vulnerability to corrupt memory outside of it, and thus to execute arbitrary code,” he wrote.

Source: www.zdnet.com

(Click Link)