Enhance Windows Security: Understanding and Utilizing the Untrusted Font Blocking Feature

Table of Contents

Windows operating systems handle fonts through the Graphics Device Interface (GDI). Fonts, due to their complex data structures and common use in documents and web pages, have historically been a potential vector for security vulnerabilities. Specifically, poorly parsed or maliciously crafted font files can be exploited in Elevation of Privilege (EOP) attacks. These attacks could allow an attacker to gain higher-level access to a user’s system when they open a document or visit a website containing the malicious font.

To mitigate this specific threat vector, Microsoft introduced a security feature in Windows 10 known as Untrusted Font Blocking. This feature provides a system-wide mechanism to prevent applications from loading fonts that are not installed in the protected %windir%/Fonts directory. By default, only fonts located within this standard system font directory are considered “trusted.” Any font located elsewhere is treated as “untrusted” and can be blocked by this feature. Implementing untrusted font blocking significantly enhances the system’s resilience against both remote and local EOP attacks that target the font parsing process.

The Concept of Untrusted Fonts and Security Risks¶

Fonts are fundamental components of the user interface and document display. They define the shapes and styles of characters. While seemingly innocuous, font files contain executable instructions (e.g., PostScript) or complex binary data structures (e.g., TrueType, OpenType). When an application loads a font, the operating system’s font-rendering engine (like GDI in older Windows versions or DirectWrite in newer ones) parses this data to render the characters on the screen or printer.

Exploits can occur if a vulnerability exists in the font parsing code. A malicious actor could create a specially crafted font file that, when processed by the vulnerable code, triggers a buffer overflow, integer overflow, or other memory corruption issues. If successful, this can lead to arbitrary code execution with the privileges of the application loading the font. Since applications like web browsers, document viewers, and even the Windows shell might load fonts from various sources (downloaded documents, websites, shared network locations), the attack surface can be broad. Untrusted Font Blocking aims to shrink this attack surface by restricting where fonts can be loaded from, assuming that the %windir%/Fonts directory is a more controlled and protected environment.

How the Untrusted Font Blocking Feature Works¶

The Untrusted Font Blocking feature operates at a fundamental system level, specifically targeting fonts processed by the Graphics Device Interface (GDI). It intercepts font loading requests and checks the location of the font file. Fonts residing outside the standard %windir%/Fonts directory are flagged as untrusted. The feature offers three primary modes of operation, allowing administrators to balance security requirements with application compatibility needs. These modes dictate how the system responds when an application attempts to load an untrusted font.

The first mode is “On,” which provides the strongest protection. When set to “On,” the system strictly enforces the rule that only fonts within %windir%/Fonts can be loaded by GDI. Any attempt by an application to load a font from an untrusted location is blocked outright. This mode also enables comprehensive event logging, recording instances where untrusted fonts were prevented from loading. This is the recommended setting for environments prioritizing maximum security, though it requires thorough testing to ensure critical applications are not negatively impacted.

The second mode is “Audit.” In this mode, the Untrusted Font Blocking feature acts passively. It continues to monitor attempts by applications to load untrusted fonts, but it does not actually block them. Instead, it logs an event whenever an untrusted font is accessed. This mode is invaluable for deployment planning. Administrators can run the system in “Audit” mode for a period to identify which applications are loading untrusted fonts and determine the potential impact of enabling the “On” mode without disrupting user workflows. The event logs provide critical information about the application executable and the font path (if applicable), aiding troubleshooting and compatibility assessments.

The third functional aspect allows administrators to create exceptions for specific applications. Even when the feature is set to “On,” certain applications can be explicitly excluded from the blocking rule. This is useful for legacy applications or specialized software that legitimately relies on loading fonts from non-standard locations. When an application is added to the exclusion list, it is allowed to load any font, including those considered untrusted by the general system policy. While this provides compatibility, it also reintroduces the font-based attack vector for that specific excluded application, so exclusions should be used judiciously and only when necessary.

Potential Reductions in Functionality¶

Enabling the Untrusted Font Blocking feature can introduce compatibility issues or reduce functionality in certain scenarios, particularly involving applications or processes that rely on loading fonts dynamically from locations other than the standard system font directory. Understanding these potential impacts is crucial for effective deployment planning, especially when transitioning from Audit mode to On mode. Identifying these issues beforehand allows for mitigation strategies, such as installing necessary fonts or creating process exclusions.

One common scenario affected is printing to shared printer servers. If a printer server utilizes the Untrusted Font Blocking feature and the spooler process hasn’t been explicitly excluded, fonts required for the print job that are not already present in the server’s %windir%/Fonts folder might not be used. This could result in documents printing with incorrect or substituted fonts, potentially altering layout and appearance. Similarly, printing processes that use printer graphics DLLs located outside the standard font directory to provide specific printer-resident fonts could also be affected, as the feature might block access to these fonts.

Applications that use memory-based fonts are also potentially impacted. Memory-based fonts are loaded directly into memory by an application without being stored as a file on disk in a standard location. While these are not file-based untrusted fonts in the traditional sense (being outside %windir%/Fonts), GDI’s processing of them can still be subject to the untrusted font blocking rule depending on how they are loaded and processed. Issues might arise if the application’s method of loading these fonts is flagged by the GDI check. This particularly affects specialized graphics or publishing software.

Viewing web pages with embedded fonts using browsers that rely on GDI for rendering can also lead to changes in presentation. Many websites use web fonts (like WOFF, WOFF2) or embed font data directly into the page using formats like EOT. When the Untrusted Font Blocking feature is active, the browser might be prevented from loading these embedded or external fonts. Consequently, the browser will fall back to using default or system fonts available in the %windir%/Fonts directory. While the content will still be readable, the intended design and typography of the website might be compromised, potentially affecting the user experience.

Similarly, viewing documents (such as Word or PDF files) that have fonts embedded within them can be affected when using desktop Office applications or other document viewers. If the feature blocks access to the embedded font data because it’s not loaded from a trusted location, the application will substitute the embedded font with a default font available on the system. This substitution can lead to changes in text layout, line breaks, and overall document appearance, potentially causing significant formatting issues, especially in documents where precise layout is critical.

How to Turn On and Use the Feature¶

Configuring the Untrusted Font Blocking feature can be accomplished through standard Windows management tools: Group Policy Editor for domain-joined or standalone machines, and Registry Editor for individual machine configuration or scripting. These methods provide flexible ways to deploy and manage the feature across an organization or on a single system.

Using Group Policy¶

Group Policy is the recommended method for configuring this feature in an enterprise environment. It allows for centralized management and consistent application of settings across many computers.

1. Open the Group Policy Management Console (GPMC) or the Local Group Policy Editor (gpedit.msc) on the target computer.
2. Navigate through the policy tree to Computer Configuration -> Administrative Templates -> System -> Mitigation Options.
3. Locate the policy setting named “Untrusted Font Blocking”.
4. Double-click the policy to edit its settings.
5. You will be presented with several options:
   • Not Configured: The default setting. The feature is off.
   • Enabled: Allows you to configure the mode.
     • Select “Block untrusted fonts and log events” to activate the feature and block untrusted fonts.
     • Select “Log events without blocking untrusted fonts” to use the Audit mode.
     • Select “Do not block untrusted fonts” to explicitly turn the feature off.
   • Disabled: Explicitly turns the feature off, equivalent to selecting “Do not block untrusted fonts” when Enabled.

Choose the desired option based on your deployment phase (Audit first, then Enabled) and click Apply and OK. The policy setting will take effect after the next policy refresh or system restart, depending on the specific policy behavior and any linked Group Policy Objects (GPOs).

Using Registry Editor¶

Directly editing the Windows Registry is an alternative method for configuring the feature, suitable for single machines or scripting deployments where Group Policy is not available or preferred. However, extreme caution must be exercised when editing the registry, as incorrect changes can cause system instability.

1. Open the Registry Editor (regedit.exe) with administrative privileges.
2. Navigate to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\.
3. Look for a QWORD (64-bit) Value named MitigationOptions. If it does not exist, right-click in the right-hand pane, select New -> QWORD (64-bit) Value, and name it MitigationOptions.

4. Double-click the MitigationOptions value to edit its data. This value is a bitmask that controls several mitigation features in Windows. It’s crucial not to overwrite existing bits that might control other mitigations. You must read the existing value and add the appropriate bit for Untrusted Font Blocking.

   • To turn on the feature (Block and Log), the bitmask value is 0x100000000000. You need to add this hexadecimal value to any existing MitigationOptions value.
   • To turn off the feature (Do Not Block), the bitmask value is 0x200000000000. Add this value.
   • To use Audit mode (Log Events Only), the bitmask value is 0x300000000000. Add this value.

   For example, if the existing MitigationOptions value is 0x1000, and you want to turn on the feature, the new value should be 0x1000 | 0x100000000000, which equals 0x10000001000. Use a programmer’s calculator or hexadecimal addition carefully.

5. After updating the MitigationOptions value, click OK.

6. Close Registry Editor and restart your computer for the changes to take effect.

It is highly recommended to back up the registry key before making any changes. Understanding hexadecimal bitmasks is essential when using the registry method to avoid unintended consequences.

Viewing the Event Log¶

Whether the feature is enabled in Audit mode or On mode, valuable information about attempted untrusted font loads is recorded in the Windows Event Log. Monitoring these events is critical during the testing and deployment phases to identify potential compatibility issues and understand which applications are being affected.

To access the relevant event logs:

1. Open the Event Viewer application (eventvwr.msc).
2. Navigate through the log tree in the left-hand pane to Application and Service Logs -> Microsoft -> Windows -> Win32k -> Operational.
3. Filter or scroll through the events to find Event ID 260. This specific Event ID is used by the Untrusted Font Blocking feature to log relevant actions.

Examining the details of Event ID 260 entries provides insights into each logged event. Key information typically included in the event details are:

• Process ID and Process Name: Identifies the application or process that attempted to load the untrusted font (e.g., winword.exe, iexplore.exe, spoolsv.exe).
• Font Type: Indicates whether the font was loaded from a file (FontType is File) or dynamically from memory (FontType is Memory).
• Font Path: If FontType is File, this field provides the full path to the font file that was accessed. This is extremely helpful in identifying the specific font causing the issue. If FontType is Memory, this field is usually blank as there is no file path.
• Mode: Indicates whether the event occurred while the feature was in “Audit” mode (the font was logged but allowed to load) or “Block” mode (the font was blocked and logged).

By analyzing these events, administrators can build a list of applications and fonts that are being affected. This data directly informs decisions on which fonts might need to be installed into the trusted %windir%/Fonts directory or which applications might require an exclusion. For example, recurring events showing winword.exe attempting to load fonts from a user’s temporary folder might indicate documents with embedded fonts causing issues.

Fixing Apps That Have Problems Because of Blocked Fonts¶

After identifying applications and fonts affected by Untrusted Font Blocking using the Audit mode and event logs, steps must be taken to address these compatibility issues before fully enabling the feature in Block mode. There are two primary methods for resolving these conflicts: the recommended method of installing the problematic fonts into the trusted system directory, and the alternative method of excluding the affected application process.

Fix Apps by Installing the Problematic Fonts (Recommended)¶

The most secure and recommended approach is to make the necessary fonts “trusted” by installing them into the %windir%/Fonts directory on the affected machines. This method ensures that the fonts are available to the system and applications without compromising the security benefits of the blocking feature, as fonts within this directory are exempt from the blocking rule.

To install a font:

1. Locate the font file(s) that are causing issues (identified from the event logs’ Font Path). Font files typically have extensions like .ttf, .otf, .fon, etc.
2. On each affected computer, right-click on the font file(s).
3. Select “Install” from the context menu. Windows will copy the font file(s) to the %windir%/Fonts directory and register them.

If the simple “Install” option does not work or is not available, you can manually copy the font files into the %windir%/Fonts folder. Once copied, you may need to open the Fonts folder (C:\Windows\Fonts) in File Explorer, and Windows will typically automatically register the fonts. Verifying the fonts appear in the list within the Fonts folder confirms successful installation. This method is preferred because it resolves the issue for the specific font globally in a secure manner, rather than punching a hole in the security policy for an entire application.

Fix Apps by Excluding Processes¶

If installing the fonts is not feasible (e.g., the font is memory-based, or the application dynamically generates fonts), or as a last resort, you can exclude the specific application process from the Untrusted Font Blocking rule. This allows the excluded application to load any font, trusted or untrusted, bypassing the security check for that process entirely. This method should be used cautiously due to the security implications.

To exclude an application process:

1. Identify the executable name of the application causing the problem (e.g., winword.exe, acrobat.exe). This information is available in the Event Viewer logs (Event ID 260, Process Name field).
2. Open the Registry Editor (regedit.exe) with administrative privileges.
3. Navigate to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.
4. Under Image File Execution Options, create a new subkey with the exact name of the application executable (e.g., Winword.exe). Right-click on Image File Execution Options, select New -> Key, and type the executable name.
5. Inside the newly created key for the application executable, create a new QWORD (64-bit) Value named MitigationOptions. Right-click in the right pane, select New -> QWORD (64-bit) Value, and name it MitigationOptions.
6. Double-click the MitigationOptions value. This specific MitigationOptions key, placed under the Image File Execution Options for an executable, controls process-specific mitigation policies.
7. Set the Value data for MitigationOptions to 0x200000000000. This specific hexadecimal value corresponds to “Do not block untrusted fonts” at the process level, effectively disabling the untrusted font blocking mitigation for this particular executable.
8. Click OK.
9. Close Registry Editor. The change should take effect the next time the excluded application process is launched.

Repeat steps 4-8 for any other application executables that require exclusion. Remember that excluding a process means that process is no longer protected by the Untrusted Font Blocking feature, making it potentially vulnerable to font-based exploits. Prioritize installing fonts over process exclusion whenever possible.

Implementing the Untrusted Font Blocking feature requires careful planning, starting with Audit mode to understand the environment, analyzing event logs to identify issues, and then systematically resolving compatibility problems either by installing fonts or creating targeted process exclusions before fully enabling the feature in blocking mode. This phased approach ensures that you can enhance security without unduly impacting critical business functions.

Conclusion¶

The Untrusted Font Blocking feature in Windows provides a significant security enhancement by mitigating a class of vulnerabilities associated with the parsing and loading of fonts from untrusted locations. By restricting GDI’s use of fonts to those within the %windir%/Fonts directory, the attack surface for font-based Elevation of Privilege exploits is substantially reduced. While the feature can potentially impact application compatibility, particularly with legacy software or specific workflows involving dynamically loaded or embedded fonts, the benefits in terms of improved security against sophisticated attacks are considerable.

Effective deployment relies on utilizing the available modes strategically: starting with Audit mode to assess impact, leveraging event logs to diagnose issues, and resolving conflicts primarily by installing necessary fonts into the trusted system directory or, as a last resort, excluding specific processes. Following these steps allows organizations to progressively enable the feature, moving towards a more secure computing environment.

We encourage system administrators and security professionals to evaluate this feature within their own environments. Have you implemented untrusted font blocking in your organization? What challenges did you face, and how did you overcome them? Share your experiences and questions in the comments below.