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 (6)

  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

  2. Russ says:

    Has the stance also changed on the Internet Explorer 11 setting recommended in the security baseline that prevents fonts from being downloaded? (Windows Components\Internet Explorer\Internet Control Panel\Security Page\Internet Zone – Allow font downloads – Enabled: Disable)

    [Aaron Margosis] Not yet, but that’s a good idea.
  3. J Cohn says:

    Why does it work in Edge, but not in IE11?

    Glad that the idea went away. Almost sounds like a way to give people a reason to shift over to Edge.

    [Aaron Margosis] Edge doesn’t use GDI to render fonts. IE does. The font blocking applies only to GDI.
  4. Bob D says:

    Would this recommendation also carry over to newer versions of Win10 (10.0.14393) or specific to 1607?

    [Aaron Margosis] This recommendation applies to all versions of Windows 10. The fontdrvhost/AppContainer mitigation has been there since the first release of Windows 10 (v1507) but wasn’t publicly documented until more recently.
  5. John B says:

    Any thoughts on the usefulness of DisableATMFD?

    [Aaron Margosis] Beginning with Windows 10 v1703 (“Creators Update”), the DisableATMFD setting is no longer applicable. The functionality of atmfd.dll has been incorporated into fontdrvhost.exe, the AppContainer-sandboxed user-mode process described in the blog post above.
  6. Does this also apply to Windows Server 2016 or only Windows 10?

    [Aaron Margosis] Yes, it applies to Windows Server 2016 also.
Skip to main content