Microsoft released a new technology preview version of its new operating system Windows 10 on January 22, 2015, and subsequently opened the download of the preview version (Build: 9926) to the public on January 24, 2015. In this new preview version of Windows 10, the kernel version has been upgraded directly from 6.4 to 10.0, but it also brings some new product forms and user experience improvements.
As a top security manufacturer in the world, 360 not only provides security protection for users using the new preview version of Windows 10 in the first time, but also pays attention to the new security features introduced in the new operating system.
Since Windows 8, Microsoft has introduced many new security features for its new operating system, including Zero-page disablement, high-entropy randomization, Control Flow Guard (CFG), Superior Mode Execution Prevention (SMEP), and so on. It has raised the threshold of application and kernel vulnerability exploitation on Windows platform. What new protections have been added to the operating system in this new technology preview version of Windows 10?
After getting the kernel and analyzing it, the first thing that comes into my sight is the two enhancements of font security in Windows 10 preview.
It should be mentioned here that before the completion of this paper (Beijing time, Jan. 24, 9am – 11am), some foreign security researchers, including Alex Ionescu (@aionescu) of CrowdStrike and Kostya Kortchinsky (@crypt0ad) of Google, also found and mentioned these two enhanced keywords on Twitter.
This article will take the reader the first time in-depth analysis of Windows 10 font protection and enhancement of the implementation and strategy to understand the context.
Security of Kernel Font Engine
For many historical reasons, Windows Kernel Mode Font Engine has long been a typical component of Windows operating system with high complexity and low code security quality. Microsoft also has to keep it in kernel mode for the sake of font engine performance. Therefore, once a security vulnerability occurs in the font engine in the Windows kernel, vulnerability attack code can be directly executed in the Windows kernel when users browse remote font files in web pages or documents. It can completely bypass almost all security protection mechanisms and has considerable lethality.
360 security researcher Wang Yu has conducted in-depth research on the security history and vulnerabilities of the kernel font engine. He made some of his technical achievements available at the International Security Conference Syscan 360 2012 (http://www.syscan 360.org/achive_2012_speech.html) and Blackhat 2014 (https://www.blackhat.com/us-14/briefings.html#understanding-tocttou-in-the-windows-kernel-font-scaler-engine). Readers interested in related technologies can learn more about them.
Historically, Microsoft has repaired many vulnerabilities in the core font, but the most famous one is to break the mystery of the font vulnerability, which may be due to the Duqu virus, the second generation of seismic network in Iran and other countries, which was disclosed by security manufacturers in 2011.
The virus uses a vulnerability in the font engine of Windows kernel (CVE-2011-3402) to embed the font file named Dexter, a haemophilic forensic doctor, into the word document. When the user opens the word document and triggers the font loading, the malicious code will run directly in the kernel mode.
This should be the first case of a publicly disclosed font vulnerability used in a real APT attack. Later, the vulnerability was transformed by some Exploit Kits into an attack version through web browsers, which began to spread and attack on a large scale.
In October of this year, Fire eye, a foreign security company, also disclosed their newly discovered font vulnerabilities for real APT attacks: (CVE-2014-4148) (https://www.fireeye.com/blog/threat-research/2014/10/two-targeted-attacks-two-new-zero-days.html). This vulnerability attack ingeniously utilizes an integer symbol problem in the font engine to execute malicious code directly from the kernel mode when browsing documents or web pages embedded with fonts, bypassing the security protection mechanism in the system and installing malicious programs.
Whether white hat security researchers or high-level hackers with national background, in-depth excavation of the security issues of Windows font engine will expose the dangerous situation of this attack more. While Microsoft is fixing bugs, it is also planning more general solutions.
On August Day, 2014, Microsoft introduced a security optimization for font caching mechanism to mitigate some font vulnerability attacks through font caching in its patch for font engine kernel vulnerabilities. These two improvements in Windows 10’s new preview are another attempt by Microsoft to mitigate font vulnerability attacks.
Windows 10 font security protection
The following author will introduce the improvement of this introduction in detail.
First enhancement: Non-system font disabling strategy
Starting with Windows 8, Microsoft introduced a new API: SetProcess Mitigation Policy. The API opens/closes some vulnerability mitigation mechanism switches of process granularity by eventually calling NtSet Information Process (Process Mitigation Policy) and setting some bits in Flags (Flags 2, Flags 3) domain of process EPROCESS object.
These mitigation mechanisms include mandatory DEP/ALSR, Zero-page memory disablement, and handle mandatory checking. In addition to this API, related switches can also be controlled by parent process inheritance, Startup Info (Process Thread Attributes), IEFO and global mitigation options.
A new mitigation option introduced this time is called Process Font Disable Policy. After setting this mitigation strategy for the process, it is shown on the tag EPROCESS – > Flags 3. DisableNonSystem Fonts, with AuditNonSystem Font Loading as an auxiliary option.
The function of this option, as the name implies, is to prohibit the loading of non-system fonts for processes, while Audit NonSystem Font Loading is the loading of non-system fonts for audit records.
So how does the system implement this mechanism? Here we’re going to look at the kernel font engine. In Windows 10, the kernel font engine is mainly located in the complete version of the Win32k kernel driver: win32full. sys.
The desktop kernel engine win32k provides multiple system call interfaces that allow user mode to load fonts into the kernel font engine, including NtGdiAddFontResourceEx, NtGdiAddFontMemResourceEx, and so on. In the kernel font engine, according to different scenarios, the following four functions are used to load and process font files:
These four functions are the key functions for the kernel font engine to load font files in different scenarios. In these functions, the kernel allocates (or directly uses) the key FontFileView (FontFileView) and calls the vLoadFontFileView function to load the FontFileView object, maps the font file data it describes into the kernel memory, and parses and processes it for later rendering.
This new preview version of Windows 10 checks before calling vLoadFontFileView in these functions to load font file view objects.
The pseudocode added to the check code is as follows (take PUBLIC_PFTOBJ:: bLoadFonts as an example):
Here we can see that the code first gets the font load mitigation option through the GetCurrent Process Font Loading Option call. If you want to know how do you recover deleted files from a usb flash drive? you can use this bug.
This function actually obtains the structure of _PROCESS_MITIGATION_FONT_DISABLE_POLICY through NtQuery Information Process (Process Mitigation Policy).
In the structure, bit0 is DisableNonSystem Fonts and Bit1 is AuditNonSystem Font Loading. Then the structure is converted into the following three option values:
0: No audit, no ban
1: Audit, Not Banned
2: Auditing and Disabling
Then, the system calls the GetFirstNonSystem FontPath function to parse the list of font files to be loaded (possibly multiple files). The function obtains the file handle of these files through IoCreateFile, and then obtains the complete path of the file object through the handle. Finally, it compares with the system font directory (% Systemroot% Fonts).
If there is a font file in the non-system font directory in the font list to be loaded, the system will first call the LogFontAttempt function and record it in the log through ETW mechanism.
The first parameter of this function is the type of trigger font loading:
[Technological Control] Deep Analysis of Windows 10 Security Mechanism: Reducing Vulnerability Risk
The second parameter is the triggered font path.
The third parameter is whether to refuse to load the font.
Next, according to the settings of the process mitigation option, the system decides whether to audit records only or reject the font loading in this case.
In the case of LoadMemFonts/LoadRemoteFonts/LoadDeviceFonts that do not contain a direct font file path at the time of invocation, the kernel will not determine the font path. If the mitigation option is set to prohibit non-system font loading, the font loading of these interfaces will be disabled and audited in all cases.
According to Microsoft’s open Windows 10 technology preview, this protection switch is not turned on by default for some key applications such as Internet Explorer and built-in PDF browser.
From the point of view of current function design, this function is more like a security measure to prevent advanced attacks for specific enterprise users. In particular, the audit function for font loading can help IT managers quickly locate possible high-level threat attacks.
It is worth mentioning that in XP Shield 2.0 of 360, we introduced a similar mechanism to the font prohibition strategy added in this update of Windows 10. Through the isolation engine mechanism of XP shield armor, we isolate the fonts in the system from those in the sandbox isolation environment, so that the fonts in the sandbox isolation environment can not be loaded into the kernel, while the fonts outside the isolation environment are not affected in the isolation environment, which achieves the same vulnerability defense effect as Windows 10.
In the XP Shield 4.0 product, we introduced a stronger lock mechanism for the kernel font engine, and the attack protection against the kernel font engine has reached a new level. The XP shield protection mechanism designed 360 years ago coincides with the new protection measures announced by Microsoft in the new generation of operating systems. It also confirms 360’s exploration in vulnerability protection research from the side.