微软在北京时间2015年1月22日公布了其新一代操作系统Windows 10的新技术预览版，并在随后的北京时间1月24日向公众开放了该预览版本的下载（Build：9926）在这个新的Windows10预览版中，内核漏洞版夲直接从/us-14//blog/threat-research/2014/10/two-targeted-attacks-two-new-zero-days.html）这个漏洞攻击巧妙地利用字体引擎中一处整数符号问题，实现在浏览嵌入了字体的文档或网页时直接从内核漏洞模式执行惡意代码，绕过系统中的安全防护机制安装恶意程序。

无论是白帽子安全研究人员还是可能具备国家级背景的高级黑客针对Windows字体引擎咹全问题的深入挖掘，都将这一攻击面的危险状况更多地暴露出来微软在修复漏洞的同时，也在计划着一些更通用的解决办法

在2014年的8朤补丁日，微软在针对字体引擎内核漏洞漏洞的补丁中就引入了一项针对字体缓存机制的安全优化，来缓和通过字体缓存进行的某些字體漏洞攻击手法这次Windows 10新预览版中的这两项改进，则是微软针对字体漏洞攻击缓和的另一次尝试

下面笔者就来详细介绍下这次引入的改進。

第一项增强：非系统字体禁用策略

这些缓和机制包括强制DEP/ALSR、零页内存禁用、句柄强制检查等除了通过这个API，相关的开关也可以通过父进程继承、StartupInfo（Process Thread Attributes）、IEFO和全局缓和选项等方式来控制

这个选项的功能顾名思义，就是针对进程禁止加载非系统的字体AuditNonSystemFontLoading则是审计记录非系統字体的加载。

那么系统是如何实现该机制的呢这里我们就要看看内核漏洞字体引擎了。在Windows 10中内核漏洞字体引擎主要位于Win32k内核漏洞驱動的完整版本: win32full.sys中。

桌面内核漏洞引擎win32k提供了多个系统调用接口允许用户模式加载字体到内核漏洞字体引擎中包括NtGdiAddFontResourceEx，NtGdiAddFontMemResourceEx等等在内核漏洞字體引擎内部根据不同的场景，主要是使用以下四个函数来实现字体文件的加载处理的：

这四个函数是内核漏洞字体引擎在不同场景下加载芓体文件的关键函数在这些函数中，内核漏洞将分配（或直接使用）关键的字体文件视图对象（FontFileView）并调用vLoadFontFileView函数来加载字体文件视图对潒，将其描述的字体文件数据映射到内核漏洞内存中并进行解析和处理，以供后面渲染使用

本次Windows 10新预览版就在这些函数中调用vLoadFontFileView加载字體文件视图对象之前，进行检查

然后，系统会调用GetFirstNonSystemFontPath函数解析要加载的字体文件列表（可能是多个文件）该函数分别通过IoCreateFile得到这些文件嘚文件句柄，再通过句柄得到文件对象的完整路径最后同系统字体目录（%Systemroot%\Fonts）进行对比。

如果待加载的字体列表中存在非系统字体目录下嘚字体文件那么系统会首先调用LogFontAttempt函数，通过ETW机制记录到日志中

该函数的第一个参数为触发字体加载的类型：

第二个参数是触发的字体蕗径。

第三个参数是是否要对该字体拒绝加载

接着，系统会根据进程缓和选项的设置决定对于这种情况，是仅审计记录还是要拒绝這个字体的加载。

对于调用时不含有直接的字体文件路径的LoadMemFonts/LoadRemoteFonts/LoadDeviceFonts的情况内核漏洞将不会判断字体路径，如果在缓和选项设置了禁止非系统字體加载则会禁用这些接口在所有情况下的字体加载并进行审计。

从微软公开的Windows 10技术预览版来看这项防护开关并没有对一些关键应用如Internet Explorer、内置的PDF浏览器等默认开启。

从目前的功能设计看来该功能更像是为特定的企业用户提供的防止高级攻击的安全措施。尤其是针对字体加载的审计功能可以帮助IT管理人员快速定位可能的高级威胁攻击。

值得一提的是在360的XP盾甲的2.0中，我们就引入了同Windows10本次更新加入的字体禁止策略类似的机制通过XP盾甲的隔离引擎机制，我们将系统中的字体同沙箱隔离环境中的字体隔离开来使得沙箱隔离环境中的字体无法加载到内核漏洞中，而隔离环境之外的字体在隔离环境内则不受影响达到了和Windows10这项防护类似的漏洞防御效果。

在XP盾甲4.0的产品中我们則引入了更强的内核漏洞字体引擎锁定机制，针对内核漏洞字体引擎的攻击防护强度又上了一个台阶360一年前设计的XP盾甲防护机制同微软公布的新一代操作系统中的新防护措施的不谋而合，也从侧面印证了360在漏洞防护研究方面的探索

第二项增强：隔离的用户模式字体引擎

茬Windows 10的新技术预览版中，针对内核漏洞字体引擎的另一项引人注意的重大改进是“用户模式字体驱动”（User Mode Font DriverUMFD）机制。

就像前面我们说到的位于内核漏洞模式的字体引擎的一旦被突破，攻击者通过精巧的数据构造可以直接从远程获得内核漏洞代码执行的能力危险极大。

同时由于字体引擎在内核漏洞中运行，因此针对字体引擎的修改也必须非常谨慎稍有不慎就可能引发大面积的蓝屏或应用程序异常。

关于修改内核漏洞字体引擎带来的副作用眼前就有典型的案例：在今年8月的补丁日中，微软的KB2982791补丁为了修复字体引擎中的安全漏洞修改了內核漏洞字体缓存引擎。结果这一改动中存在的兼容问题不幸引发了大面积的用户Windows系统启动即蓝屏的问题。该问题遭到了大量用户和媒體的指责微软不得不宣布将该补丁撤回重发。

在这个Windows 10技术预览版中微软首次建立了用户模式和内核漏洞模式的字体引擎交互机制，将內核漏洞字体引擎中的多个字体驱动引擎移植到用户模式使得字体引擎能够部分在隔离的用户模式进程中运行，同时也保留了内核漏洞模式字体引擎驱动的机制尽量将可能出现安全漏洞的渲染引擎放到用户模式，同时使用一些内核漏洞预先加载、内核漏洞/用户模式交互嘚方式减少这种模式对于性能的损耗。

在这套机制应用后如果相关的字体引擎代码出现安全漏洞，攻击者只能控制被隔离的用户模式芓体驱动宿主无法通过字体漏洞直接控制操作系统内核漏洞。而修复相关漏洞的成本和可能的风险也将大大降低。

这里笔者将主要介紹这套新的UMFD机制的运作原理和一些关键细节限于时间和篇幅的原因，关于UMFD很多具体实现、实际性能状况、实际漏洞隔离效果等这里无法详尽地覆盖到，感兴趣的读者可以去深入逆向、分析和测试相关的代码和功能来发现更多的内容也可以在本Blog同笔者讨论。

根据我们的嶊测UmfdLoadFontFileView应该就是用户模式字体驱动（UMFD）的字体加载函数。如何证实这点呢该函数又是如何同用户模式的字体驱动引擎交互的呢?

在该函数Φ，我们可以看到它会调用UmfdHostLifeTimeManager::EnsureUmfdHost该函数是用户模式的字体引擎宿主的生命周期管理函数，用于确保用户模式的字体引擎宿主客户端存在

接丅来的一个关键步骤是通知UMFD的驱动部分，在UMFD的内核漏洞部分引擎中注册fontdrvhost.exe这个用户模式客户程序

NtGdiExtEscape过去被win32k内核漏洞部分用于同gdi32进行一些内核漏洞/用户模式交互，在新的Windows10预览版中该函数被umfd使用来进行umfd的相关内核漏洞交互，是UMFD的内核漏洞/用户模式交互基础

在UmfdDispatchEscape中，内核漏洞提供叻一些用户模式字体驱动客户端所需要的内核漏洞-用户模式数据交互、文件映射与访问接口等这个后面我们会提到。

上面我们说到的是UMFD鼡户模式客户端的创建以及它同内核漏洞模式部分通讯的过程

接下来，我们回到刚才说的vLoadFontFileView函数过程上面我们说到在注册用户模式字体宿主进程后，内核漏洞会置UmfdHostLifeTimeManager::s_WinlogonCallbackEvent事件来通知UMFD用户模式部分已经开始工作并使得字体加载过程继续下去

那么接下来，内核漏洞就开始进行实际嘚用户模式字体加载通过调用PDEVOBJ::LoadFontFile，实际上内核漏洞会Attach到CSRSS进程上并调用UMFD的字体加载接口函数：UmfdLoadFontFile来完成字体加载。

当对应的内核漏洞模式接ロ被调用时实际也是由这些接口函数使用UmfdClientSendAndWaitForCompletion发送请求到UMFD用户模式处理队列中，通知用户模式客户端来完成实际的字体工作的

在宿主从内核漏洞获得字体操作请求数据返回用户模式后，用户模式字体驱动宿主再使用DispatchRequest函数分发到内核漏洞的字体处理请求到各个用户模式字体驱動接口中

这些用户模式字体驱动目前也都是编译在fontdrvhost.exe这个进程的代码中的，主要有ttf字体驱动、bmf字体驱动和vtf字体驱动等相关的处理代码

在處理内核漏洞字体请求时，DispatchRequest会根据请求数据中指定的设备和指定的请求类型（QueryFontData,LoadFontFile…)来选择不同的字体驱动处理例程进行最终的字体处理过程

值得一提的是，在用户模式字体引擎中包括针对字体虚拟机的指令实现部分（itrp_*函数），也是在用户模式中实现的

最近几年被曝光用於真实攻击的内核漏洞模式字体漏洞，都是在特定的itrp_*函数处理数据中发生的安全问题也都需要依赖itrp_*函数来操纵内核漏洞数据来实现最终嘚漏洞攻击。这项新的增强将这些函数隔离在低完整性级别的受限用户模式进程中显然极大地提高了这类漏洞的攻击难度和利用门槛。

簡单总结来说UMFD这套机制实际上就是通过在内核漏洞并行纯内核漏洞模式字体引擎和需交互的用户模式字体引擎两套系统。在系统启动过程中使用性能更好的内核漏洞模式加载不会有安全问题的、已注册的系统字体文件

在系统启动完成并开始加载非本地的字体文件时，就開启用户模式字体引擎通过Winlogon控制的用户模式字体引擎客户端fontdrvhost.exe，利用NtGdiExtEscape同内核漏洞进行交互为内核漏洞的UMFD部分实现字体文件的解析、渲染笁作，并给内核漏洞模式返回需要的接口

两套接口并行、对外保持一致的数据交互，在不影响功能、消耗非常见情况下的较少性能的前提下实现了字体数据解析和渲染的用户模式+受限权限隔离。

即使字体解析和渲染过程中存在安全漏洞也被限制在受限的用户模式进程Φ，需要进一步利用其他安全漏洞才能最终完成攻击无法再直接获得内核漏洞的最高权限，使得这类型漏洞的风险大大降低也使限制、发现这类漏洞攻击更容易和更具备可能性。

本文所介绍的非系统字体禁用和用户模式字体驱动机制都是微软在内核漏洞模式字体引擎漏洞攻击方面的缓和措施，分别通过安全策略、安全隔离的思想提高内核漏洞模式字体引擎漏洞的利用难度，降低了相关漏洞的安全风險在特定的环境下，甚至可能完全杜绝远程字体漏洞的攻击这个安全措施称得上是继默认开启CFG后，Windows10又一可圈可点的新安全特性

如同CFG茬Windows10中默认开启后，逐步开放到Windows8.1 Update3的更新上希望这个机制也能尽早磨练成熟，升级到后续的操作系统中为更多用户提供更好的安全保障。

这是内核漏洞漏洞挖掘技术系列嘚第三篇

上一篇文章我们讲解了内核漏洞double fetch漏洞和Project Zero的j00ru开源的这种漏洞的挖掘工具bochspwn()的原理。这一篇文章我们继续讲解内核漏洞中未初始化导致的信息泄露漏洞和Project Zero的j00ru开源的同样基于bochs的插桩API实现的这种漏洞的挖掘工具bochspwn-reloaded()的原理环境搭建可以直接参考github上的文档，可能会遇到的问题也茬上一篇文章中有说明所以就不再赘述环境搭建的步骤了。由于内容比较多所以文章分成两篇，这一篇基于论文讲解信息泄露漏洞和bochspwn-reloaded嘚设计下一篇讲解bochspwn-reloaded的代码和信息泄露漏洞的其它挖掘方法。

为什么会造成信息泄露漏洞

内核漏洞中信息泄露漏洞的产生主要有两方面的原因一是C语言带来的问题，二是内核漏洞设计和编程模式带来的问题

在C语言中未初始化变量会继承其相应内存区域的旧值。比如下面這样的系统调用每次就会泄露栈上的四个字节
但是这样单个变量的信息泄露其实并不是很常见，因为编译器通常会警告也较容易在开發和测试的过程中发现。在下面这样的系统调用中结构体中的Reserved成员没有被用到但是也会被拷贝回用户态，同样会泄露栈上的四个字节

結构体中的所有成员和整个结构体都是对齐的。在必要的地方填充字节被人为地插入到结构体中。虽然不能在源代码中直接访问但是這些字节仍然继承了相应内存区域的旧值。下面的系统调用中结构体中的每个成员都被正确初始化但是由于存在填充字节，所以仍然会慥成信息泄露
对于这个问题，有下面这几种解决方案：

1. 在代码中声明填充字节并初始化
2. 将结构体序列化为字节缓冲区并在另一端反序列化。

1需要花费程序员大量额外的精力；3可能会造成内核漏洞性能下降；我猜测2可能是内核漏洞开发实践中比较好的一个解决方案

联合體中不同大小的成员

如果联合体由不同大小的成员组成并且只设置了较小的成员，为较大的成员分配的剩余字节就没有初始化下面的系統调用中联合体是8个字节，但是只设置了较小的成员的值因此剩下四个字节未初始化，造成信息泄露

在前面的例子中我们可以看到，sizeof操作符的使用和内核漏洞信息泄露有直接的关系因为它导致最终复制的数据比初始化的数据更多。更深层次的原因在于C语言缺少在不同層次之间安全传输数据的功能如果不采取编译器/操作系统/语言规范这样级别的解决方案，这样的漏洞可能长期存在

内核漏洞设计和编程模式带来的问题

前面几个例子都是重用了栈上的值，在windows/linux中也存在动态分配的内存重用机制同样会导致信息泄露的风险。

大的缓冲区很尐被全部使用剩下的空间通常不会被重置，这可能导致特别长的连续的内核漏洞内存泄露下面的系统调用中RtlGetSystemPath函数加载系统路径到一个夲地缓冲区，如果调用成功所有260个字节都传递给调用者而不考虑字符串的实际长度。

分配缓冲区未全部初始化

大多数系统调用接受指向鼡户态缓冲区的指针以及缓冲区的大小在大多数情况下，关于大小的信息应该只用于确定缓冲区是否足够大以接收系统调用的输出数据但不应该影响复制了多少内存。但是内核漏洞中存在试图填充用户态缓冲区的每个字节而不考虑要复制的实际数据量的情况下面的系統调用目的是提供给用户态3个32位的值，一共12个字节在检查用户态缓冲区大小足够之后，内核漏洞本来可以分配一个12字节的缓冲区然后拷貝到用户态但是内核漏洞根据用户态传入的OutputLength分配缓冲区并全部拷贝到了用户态。用户态只需要12个字节的数据剩下的字节没有初始化并苴泄露给了用户态。

bochspwn-reloaded的原理是污点追踪污点信息记录在bochs进程的shadow memory内存区域中，将每个字节映射到相应的元数据在32位系统中，除了污点标記之外元数据还包括下面这些信息。

• size：内存分配的大小
• origin：请求分配的指令的地址

为了节约空间除了taint之外其它信息的粒度由1个byte增加到8个byte。类型、粒度和内存使用情况如下

用伪代码表示的栈污点标记的大致逻辑如下。指令执行前的回调函数标志指令是否会修改栈指针指囹执行后的回调函数检查标志，如果栈指针被修改并且ESP变小了对ESP(new)-ESP(old)做污点标记。
对于32位的windows系统还有两个问题
1.在32位的windows系统中有一个内置的chkstk函数，它等价于alloca相关代码如下所示。高亮的xchg eax, esp将更新后的esp保存到eax中为此我们需要读取eax寄存器中的值作为origin。


在32位的windows系统中函数遵循stdcall调用约萣即参数存储在栈上，返回值存储在EAX寄存器windows内核漏洞中几乎所有的内存分配函数最终都会调用ExAllocatePoolWithTag函数，hook这个函数就可以获得内核漏洞中幾乎所有内存分配的信息

通过RCX，RDX和R8寄存器将参数传递给ExAllocatePoolWithTag函数的参数当函数返回时可能其中的值已经被更改。所以需要hook函数两次第一佽读取origin和size，第二次读取base address根据这些信息做污点标记。
需要特别注意的一个情况是内核漏洞中特定子系统使用的内核漏洞分配器比如下面昰win32k!AllocFreeTmpBuffer函数的伪代码。内存区域只分配一次而且永远不会释放，但是图形子系统的多个部分会重用它这对我们的检测不利。我们可以patch代码讓它每次都会调用AllocThreadBufferWithTag函数

在linux x86系统中hook了更多的函数，但是原理类似下一篇文章讲解代码时再详细提。

当检测到内核漏洞到内核漏洞的数据拷贝时进行污点传播

1.源缓冲区和目标缓冲区重叠
2.目标指针不是4字节对齐的
3.复制长度小于32字节
4.复制长度不是4字节对齐的
1，24这几种情况都仳较罕见，比较麻烦的是3它可能会导致内核漏洞地址空间中大量较小对象没有被标记污点。解决方法仍然是patch代码将下面cmp ecx, 8改成cmp ecx, 0使得rep movsd指令詠远都会被调用(同样也要patch memmove函数)。

在64位windows上有两个处理逻辑
1.内存拷贝函数不再使用rep movs指令，而是被优化成mov指令和等价的SSE指令的形式因为它们嘟有共同的实现，所以在配置文件中设置了memcpy_signature匹配上了就调用handle_memcpy函数进行污点传播。
2.更高的windows版本上越来越多固定长度的memcpy被编译为内联的mov指令序列而不是rep movs指令或者直接调用库函数。

当检测到内核漏洞到用户的数据拷贝时插桩指令检测到含有未初始化的字节就报告漏洞
在linux中，囿两个接口可以方便地将数据从内核漏洞态写入用户态：copy_to_user和put_usercopy_to_user等价于memcpy，符合我们漏洞检测的逻辑；put_user允许内核漏洞将字符或整数等简单的数據类型直接写入用户态在二进制层面数据是通过寄存器传递的。这种类型的信息泄露我们前面通用的漏洞检测逻辑就检测不到了
在代碼中我们可以看到传递给用户态的数据被存储在名为__x的本地辅助变量中。
我们修改这个宏添加下面两个指令。
在bochs中prefetcht1和prefetcht2指令由BX_CPU_C::NOP方法处理這使得它们成为用作hypercall的主要候选对象——对guest的执行没有任何影响，而是用于与模拟器通信的特殊操作码在这种情况下，插桩指令检测prefetcht1的執行把它当作一个信号。如果此时读取了未初始化内存以同样的方式报告潜在的漏洞。prefetcht2指令禁用了该信号