Google makes Chrome for Windows more resilient to vulnerability exploitation with new mitigation technology
Starting in version 90, Chrome for Windows improves resilience against vulnerability exploitation by adopting Hardware-enforced Stack Protection.
With this mitigation technology, which is available in Windows 10 20H1 or later, on processors that feature Control-flow Enforcement Technology (CET), the processor maintains a shadow stack of valid return addresses, which makes it more difficult for bad actors to write exploits.
Together with existing protection measures, the Stack Protection should mitigate a variety of exploitation techniques, but could affect stability if it is not compatible with software that loads itself into Chrome.
While Data Execution Prevention has long prevented making stacks or heaps executable, the use of Return Oriented Programming (ROP) allows attackers to point to a different piece of code that they can abuse.
Chrome’s multi-process architecture reduces the severity of vulnerabilities in the renderer, but the manner in which libraries are mapped in processes by Windows allows attackers to search for ROP gadgets in Chrome’s binary and loaded libraries.
With stack-protection, a shadow stack that the CPU maintains alongside the existing stack, which only stores return addresses, cannot be directly manipulated by program code. Return addresses are pushed to both stacks and the RET (return) instruction verifies that the return address it takes from the normal stack is identical to the one stored in the shadow stack.
The program continues to work only if the two return addresses match, otherwise an exception is raised and is intercepted by the operating system, which has the option to change the shadow region and allow the program to work. Normally, however, the exception should result in the program being immediately terminated.
Thus, even if an attacker manages to make an initial jump into a ROP gadget, they will be stopped when attempting to return to their next gadget.
Google explains that some software may not be compatible with the mechanism, and that the Stack Protection has some limitations, such as the fact that Chrome doesn’t support every direction of control flow enforcement for the time being.
“Stack protection enforces the reverse-edge of the call graph but does not constrain the forward-edge. It will still be possible to make indirect jumps around existing code as stack protection is only validated when a return instruction is encountered, and call targets are not validated,” Google explains.
Furthermore, there are contexts in which it is possible to bypass stack protection by itself, such as when the attacker replaces an object containing a function pointer, to trick a program into calling the function. However, most functions are not useful to an attacker, Google says.
The protection can’t prevent the actual vulnerabilities, especially if they may allow for arbitrary writes that could be abused to run arbitrary code.