Dropping the “Untrusted Font Blocking” setting


With the Windows 10 v1703 security configuration baseline, Microsoft is removing the recommendation to enable the “Untrusted Font Blocking” Group Policy setting in Computer Configuration | Administrative Templates | System | Mitigation Options. Windows 10 includes additional mitigations that make this setting far less important, while blocking untrusted fonts breaks several legitimate scenarios unnecessarily.

Parsing and rendering font data involves significant complexity, so it is not surprising that font-rendering engines have had bugs – particularly when handling font data that does not conform to expected formats. Nor is it surprising that malicious actors target these bugs with malformed font data to deliver exploit code through web pages and document files that support embedded or downloaded fonts. On versions of Windows prior to Windows 10 and Windows Server 2016, that problem has been compounded for programs that use Windows’ graphics device interface (GDI) APIs to load and render fonts. In addition to the threat of remote code execution in a compromised user-mode process, a GDI font-rendering bug can also result in kernel-mode execution and local elevation of privilege because most of GDI’s font logic was in Win32k.sys which runs in kernel mode.

The first release of Windows 10 introduced a new Group Policy setting, “Untrusted Font Blocking,” that offers a powerful mitigation against attacks on GDI’s font logic. Our prior security baseline configuration recommendations for Windows 10 have included the enforcement of this setting. The setting enables IT admins to disallow all programs from using GDI to load and render font data from any location outside of the %windir%\Fonts directory. Only administrators can put files into the Fonts directory, so this setting keeps standard user programs from using GDI to handle fonts downloaded through web pages, embedded in Office or PDF documents, or downloaded by users. Note that this block applies only to font-rendering through GDI and not to other user-mode font-rendering engines such as DirectWrite which is used by the Microsoft Edge and Google Chrome web browsers.

It turns out that at the same time, Windows 10 introduced a separate, always-on mitigation against GDI font-rendering bugs. However, Microsoft didn’t publicly discuss it until an August 2016 BlackHat presentation, Windows 10 Mitigation Improvements (see p. 34), and in a January 2017 blog post, Hardening Windows 10 with zero-day exploit mitigations (see the “Mitigating font exploits with AppContainer” section).

With Windows 10, GDI font parsing is no longer performed in kernel mode. Instead, it is performed in a sandboxed user-mode process, fontdrvhost.exe, which executes in a highly-restricted, per-session AppContainer process under a limited-scope, system-generated virtual account. The AppContainer process is granted no Capabilities and minimal privileges. (When a process in an AppContainer requests access to a resource, the Windows security access check applies tighter rules than it does for traditional, non-AppContainer processes, granting access only if the resource explicitly grants access to it.)

One of the most visible downsides of blocking downloaded and embedded fonts is that many web sites rely on them, and blocking them can substantially diminish usability. For example, here is the MSN home page’s banner rendered in Microsoft Edge, which is not affected by the Untrusted Font Blocking setting:

And here is the same banner rendered in Internet Explorer with font-blocking enabled:

As you can see, the MSN and Bing logos are represented using downloaded fonts, as are most of the Microsoft application logos. In addition to app logos, Microsoft’s Office 365 also makes liberal use of downloaded fonts for web application graphics such as navigation aids and actions such as “delete” and “flag this message.” These screenshots show the differences: the first shows Microsoft Edge without font blocking; the second shows Internet Explorer with font blocking enforced:

  

With GDI font parsing performed in a restrictive AppContainer, the risk of handling untrusted fonts in GDI is now acceptably low enough that we feel confident that the costs of font-blocking exceed its benefits. Therefore, we are removing our previous recommendation to enable untrusted font blocking.


Comments (1)

  1. David B says:

    We initially used this but had to turn it off because of the exact website issue you described. Glad MS was able to mitigate this in a different way

Skip to main content