Chrome + Windows Exploit: Security Beyond Bugfixes

Earlier this week the Google Security Team disclosed a pair of vulnerabilities, known to be exploited in the wild, one in Windows and the other in Chrome. These represent a fairly standard exploit chain: code execution in Chrome’s sandboxed renderer process and then a kernel bug to escape the sandbox and gain privileged code execution.

There’s a publicly visible patch for the Chrome bug, however there aren’t a lot of details on the Windows kernel bug. The Google team states that they think it may be only possible to exploit this bug against Windows 7, and not newer Windows versions – even if the bug does exist there. I want to use the remainder of this post to explain reasons that is – based on the information we have.

It’s very common to think about computer security primarily in terms of fixing vulnerabilities. In reality, security teams spend a lot of their time on a different goal: making bugs hard to exploit. This often takes the form of lowering privileges and introducing exploit mitigations. Windows 10 has a lot of investment in those areas, whereas Windows 7 doesn’t contain any of the improvements made in the last several years. That’s why even though Windows 7 continues to receive security bug fixes from Microsoft, it is considerably less safe to use.

There’s a few mitigations and sandboxing improvements that look relevant to this vulnerability:

win32k.sys syscall disable policy

Windows has two sets of syscalls: Windows NT, which contains typical OS functionality such as process management and file system access, and win32k, which contains GUI functionality. win32k is known to contain a very high number of vulnerabilities. Starting in Windows 8, Microsoft introduced an option for processes to totally disable their own ability to use win32k, for processes that didn’t want it to be used for exploitation. Chrome takes advantage of this option.

This exploit was against a win32k syscall, so in Windows 10 it would not have been possible to reach this vulnerable code from the sandboxed Chrome process.

NULL page mapping

This vulnerability type was a NULL pointer dereference. It’s relatively rare to see this as a vulnerability type – usually NULL pointer dereferences are just crashes, not security issues. However, against a kernel it’s possible for a NULL pointer dereference to access the userspace process’s memory at the NULL page, instead of simply crashing.

Starting in Windows 8, processes are not allowed to map the NULL page, which probably would have prevented exploiting this vulnerability.

Supervisory Mode Execution and Access Prevention (SMEP and SMAP)

These are two processor technologies which prevent higher-privileged code (i.e. the kernel) from accessing lower privileged code’s memory (e.g. the sandboxed Chrome process) by default. When the kernel wants to read a userspace process’s memory it explicitly disables SMAP briefly, and then turns it back on. This means that kernel vulnerabilities can’t be exploited to read things (such as pointers or shell code) from a userspace process. This means accidental dereference bugs like the one here are harder to exploit.

Windows began leveraging SMAP and SMEP in Windows 10.

Conclusion

The combination of these mitigations and sandboxing improvements makes exploiting bugs in Windows 10 much harder than in Windows 7. Users still on Windows 7 should be upgrading. There’s more to security than just fixing vulnerabilities.