Return of JIT
Some time back, Chromium introduced a new toggle named V8 optimizer that allowed users to disable JavaScript just-in-time (JIT) compilation. This feature dramatically enhanced security by reducing the attack surface at the cost of slightly degraded performance. For reference, V8 JIT compiler bugs have accounted for roughly 45% of all the CVEs issued for V8 at some point in time.
Long before the birth of this toggle, however, there existed and still exists a V8 command-line flag called --jitless.
Now that there are seemingly two options to achieve the same objective, which should you choose? Or should you leverage both of them as a fail-safe such that even if the command-line flag gets overwritten someday, the toggle would still protect you?
If your answer was the latter, you might find the results surprising.
The WASM Connection
At the time of writing, the V8 JavaScript engine broadly comprises the following components:
When JavaScript JIT compilation is disabled, runtime allocation of executable memory is disabled, and V8 switches into an interpreter-only mode. All JavaScript code runs through Ignition.
WebAssembly (WASM) support is currently reliant on JIT compilation, more specifically on a new baseline non-optimizing JIT compiler (code-named Liftoff). Even in the interpreter-only mode, WASM still requires RWX memory to run. Ergo, it is presently unsupported when JavaScript JIT compilation is disabled.
I’m told that Microsoft Edge has its own WASM interpreter (code-named DrumBrake), which would explain how they could support WASM without requiring JIT.
So, what’s happening above? How exactly are we getting WASM support?
The short answer is that WASM works again because the JIT has returned!
领英推荐
The long version is that two things are happening here:
To the best of my knowledge, Daniel Micay and the developers behind GrapheneOS were the first to spot this change.
As to why they made this change, not breaking WASM seems like a good guess. But then again, this toggle is neither enabled by default nor officially recommended. The ones opting for it probably knew what they were doing and were possibly fine with not being able to run WASM code.
The Fix
As counter-intuitive as it may sound, the fix is as simple as leaving the V8 optimizer toggle in its default state, i.e. Sites can use the V8 optimizer.
Instead, you can pass the correct V8 command-line flag to your choice of Chromium-based browser:
--js-flags=--jitless
This will ensure that V8 runs in jitless mode.
Closing Thoughts
With everything said, I sincerely believe that the average internet user need not be bothered about anything mentioned here. Contrary to popular belief, the everyday connoisseur of cat videos on the internet isn’t facing a heightened risk of targeted attacks against web browsers using complex and expensive 0day chains simply because they possess little/no intelligence value. Regular users face much bigger threats from ransomware and cybercrime groups via breached passwords, poor password policy, lack of MFA, and so on.
This advice is geared more toward people and organizations who have valuable secrets worth protecting. Some examples include:
PRO TIP: Use Microsoft Windows 11 as a secure desktop OS. Use Intel? Core? Ultra processors with Intel vPro? Enterprise. Enable Virtualization-based Security (VBS). Use Microsoft Edge web browser. Enable Enhanced Security Mode. Use Microsoft Defender Application Guard (MDAG) to initiate hardware-isolated browsing sessions. Adversaries would need an additional Hyper-V Virtual Machine Escape (VME) bug apart from the usual browser renderer Remote Code Execution (RCE), browser Sandbox Escape (SBX), and guest Local Privilege Escalation (LPE) bug chain.