Microsoft's Edge Vulnerability Research (VR) team last week announced the start of testing Microsoft's Super Duper Secure Mode (SDSM) for Edge, which works by removing Just-In-Time (JIT) compilation from the V8 processing pipeline.
SEE: This new phishing attack is 'sneakier than usual', Microsoft warns
Per MS Poweruser and Reddit users, unstable Edge Canary now includes a flag that enables SDSM in Edge. That is, JIT compilation in V8 in Edge is disabled by going to: edge://flags/#edge-enable-super-duper-secure-mode
Microsoft is not alone in taking new approaches to the V8 engine's JIT compilers. Google Project Zero is also exploring how to tackle vulnerabilities surrounding JIT compilation in V8, but with a different solution -- namely, creating a custom sandbox for V8.
Since Microsoft Edge is based on Chromium and Google Chrome is the most widely used browser on Windows, there is a mutual area of concern for both firms.
With V8's JIT compilation turned off, Microsoft could enable Edge memory and hardware-based protections -- such as the hardware-based Control-flow Enforcement Technology (CET) from Intel, and Windows' Arbitrary Code Guard (ACG) and Control Flow Guard (CFG) -- that were previously incompatible with JIT.
Google is not unaware of this, but some within Google believe that the benefits of these hardware-based protections might not be as effective as believed. Interestingly, in May, Google's Chrome team opted to enable Intel's CET mitigations for Chrome on Windows 10 to mitigate return-oriented programming (ROP) attacks.
Earlier this month, Google Project Zero researcher Samuel Groß outlined a sandbox approach to tackle JITs within the context of V8. He warned that his proposal had many hurdles to cross. Those hurdles could come from other teams within Google, such as the Chrome team, from Microsoft, or from other interested parties.
SEE: Legacy IT: Saving money by holding onto old tech is costing us all billions
Groß explained that the problem with V8 stems from JIT compilers that can be used to 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," Groß said.
"This appears to be a somewhat natural problem of JIT compilers for dynamic languages, as one of their major purposes is to remove (redundant) runtime checks that would otherwise be performed by the interpreter."
He's less confident in the technologies that Microsoft researchers highlight would be enabled by switching JIT compilers off -- and hence why the better approach may be to create a custom sandbox for V8.
As Groß also noted, CPU side-channel vulnerabilities, and the potency of V8 vulnerabilities, mean that "upcoming hardware security features such as memory tagging will likely be bypassable most of the time."
Microsoft tests Super-Duper Secure Mode for Edge
Google Project Zero testing 30-day grace period on bug details to boost user patching