Chrome picks up bonus security features on Windows 10

The Windows 10 November update (version 1511, build 10586) included a handful of new security features to provide protection against some security issues that have kept on popping up in Windows for a number of years. Google yesterday ^[1] added source code support for these features to the Chrome browser, making Windows 10 the best version of Windows to use with Google's browser.

Over the last few years, Windows has had a number of flaws that relate to its font handling. The TrueType and PostScript fonts that Windows supports are complex things, and for historic reasons, much of the code used to handle these fonts runs in Windows' kernel mode. This makes it attractive to attackers: if a bug exists in this font-handling code, it can be used to obtain kernel-level privileges.

Compounding this, the code is also quite exposed: a Word document, for example, can contain its own embedded fonts, and opening the document means that those embedded fonts will be loaded into the kernel. If the fonts are malicious, constructed to exploit bugs in the font-handling code, this can compromise your system simply by opening a document.

Windows 10 includes a way to block applications from loading their own fonts, restricting them to only being able to use the ones in Windows' Font directory. This is off by default because of compatibility concerns: various applications expect to be able to load their own fonts, and simply prohibiting the capability outright would leave those applications unable to properly show their documents.

The way this was done in Windows 10 wasn't suitable for Chrome; it was a system-wide setting, and though it could be overridden on a per-executable basis, Chrome, which spawns a multitude of sub-processes all with different security restrictions and needs, couldn't easily opt in. Windows 10 November update added finer control so individual processes could enable the new restriction. This should have no impact on Web fonts or PDFs with embedded fonts, because those don't use the Windows font handling anyway.

In late 2014, Google reported a flaw in Windows 8.1 ^[2] that potentially enabled malicious code to break out of the sandbox restrictions that Chrome builds. Chrome uses a Windows feature called "job objects" as part of its sandbox system. Job objects are used to apply various kinds of restrictions to sets of processes. One thing that Chrome uses the job objects for is to ensure that its sandboxed processes can't create child processes of their own. The point of this restriction is to make it harder for exploits running in the sandbox to create unrestricted, non-sandboxed processes.

Google discovered that even when a job object prohibited the creation of child processes, this restriction could be bypassed by the Windows console system. This was necessary, once again, for historic reasons. In old versions of Windows, console windows were actually handled by a shared, privileged Windows process. This opened up certain security issues, so in Windows 7 console windows were moved out of this privileged process and into a bunch of separate processes (they show up in Task Manager as conhost.exe).

But this introduced a legacy issue: an application that was part of a restricted job in Windows XP could create a console window without issue, as doing so didn't require creating any more processes. Run that same application on Windows 7 and it would run into a problem: creating a console window also requires the creation of a new process (conhost.exe) which the restricted job object isn't allowed to do.

Microsoft resolved this by treating the console window specially and allowing it to ignore the job object restrictions. It was this behavior that Google reported as a bug in December 2014. Microsoft said that it would not be changing Windows' behavior because of the compatibility issues it would raise, so Google went public with the bug in February 2015.

The Windows November update included a new API to allow applications to opt in to a stricter restriction that stops them from creating child processes, including the special console processes. As this is a new API in Windows 10, the issue of breaking software that used to work no longer arises. Chrome now uses this ability to further lock down its sandboxes, addressing the issue that Google discovered previously.

The last change Google has made shows another way in which Microsoft is trying to shore up Windows and how its efforts to do so are balanced against compatibility concerns. Windows programs typically use libraries (DLLs) in addition to the main executable file. These DLLs can reside on networked locations, and loading a DLL from the network is one way in which exploits can load their malicious payloads. This provides convenient flexibility for the exploit developer, as it means that the exploit itself (often limited in terms of size and capability) only needs to do a small amount of work.

Again, this is not something that Microsoft can unilaterally ban; people use programs installed on network drives, and those programs need to be able to load libraries from those network drives. As such, this is another opt-in protection that can be configured programmatically, and Google is doing so in Chrome. Chrome is also using a new, similar protection to block loading of executables that are labelled as being "low integrity." Low integrity processes are prohibited from writing to most parts of the disk, including most of the user's home directory. The purpose of this restriction is less clear.

None of these are major new security features in themselves. They're all defense-in-depth features, designed to mitigate the effect of security flaws, even those flaws that aren't currently known. They also show some of the security trade-offs that Microsoft has to make: with modern, actively developed software such as Chrome, free from many of the constraints of legacy compatibility, there's more scope for a tighter approach to security.

The new APIs also highlight the way that not all the work Microsoft does on Windows is splashy and high-profile. These are incremental improvements in response to security criticisms and issues identified by experts, and they serve to make Windows 10—and Chrome on it—harder to take advantage of even in the face of software flaws.