win32k.sys驱动CreateSurfacePa的本地提权漏洞分析(CVE-2019-1362)(下)

xiaohui 漏洞 2019年12月25日发布
Favorite收藏

导语:本文讲的这个漏洞是最新发现的一个Windows 7本地权限升级(LPE)漏洞,目前该漏洞已经被定义为CVE-2019-1362。

上一篇文章中,我们介绍了漏洞发生的运行环境和运行过程。在这一篇文章,我将介绍漏洞的实际攻击过程,并对其进行分析。

1.每个池内存块(大块除外)前面都有一个POOL_HEADER记录,我们需要在伪造的_PALOBJ结构之前欺骗一个池标头。

2.释放一块内存时,用下一个池标头的内容验证它的池标头的内容。因此,我们还需要在fake _PALOBJ结构上创建一个额外的伪造池标头。

3.池标头(PoolIndex字段)中有一个字段包含内存块所属的池的索引。

4.在正常情况下,尽管理论上最多可以分配16个池,但是在操作系统中可以使用4个池。每个池都通过使用其描述符POOL_DESCRIPTOR记录进行管理。

5.我们将使用一种名为“PoolIndex Overwrite”的池利用技术,尽管在我们的示例中,“Overwrite”部分不是一个技巧,因为我们的伪造池头位于用户内存中,所以我们可以随意向它们写入。我们将伪造池头中的PoolIndex字段设置为15。内核使用一个表将PoolIndex值转换为相应的POOL_DESCRIPTOR记录的地址。由于只分配了4个池,因此PoolIndex为15的值将转换为空指针。

在x86上默认安装Windows 7时,可以通过调用ntdll.dll!NtAllocateVirtualMemory本机API来分配一个空页(内存从地址0开始)。 (此外,请注意,可以使用注册表项HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory的EnableLowVaAccess启用或禁用空页分配。)这使我们可以在此处分配伪造的POOL_DESCRIPTOR结构。就我们的目的而言,足以初始化此结构的PendingFrees,PendingFreeDepth和ListHeads字段,如前面提到的“ Windows 7上的内核池利用”中所述。这将导致能够用半控制值覆盖我们选择的内核内存。

根据物理安装的RAM内存的数量,操作系统要么立即将要释放的内存块返回池中,要么以较大的突发次数(称为“延迟释放”)返回到池中。根据该变量,通过使用精心设计的POOL_DESCRIPTOR结构,我们可以使用释放的内存块地址(在本例中为DWORD,格式为0x30XXXXXX)或某些用户的地址覆盖我们选择的内核内存。该内存块在准备我们精心设计的POOL_DESCRIPTOR结构时分配(该值范围从0x00010000到0x7fff0000)。我们最后的非显而易见的任务是在内核中找到一个很好的覆盖目标,该目标的某些值通常未知,但保证至少为0x10000。

有这样的约束,调色板对象就是一个不错的选择。可以使用gdi32.dll!SetPaletteEntries API将调色板条目写入。在其内核实现中,此API对请求写入的索引强制执行0xffff的限制。这是因为无法在用户模式下创建较大的调色板。我们可以创建一些调色板(将其命名为PaletteLO),例如,包含256个条目。仅在请求的要写入的调色板条目在0到255的范围内时,在PaletteLO上调用SetPaletteEntries才会成功。然后,我们可以使用上述利用方法,使用未知值覆盖PaletteLO的_PALOBJ内核结构中的cEntries字段。至少0x10000。完成此操作后,SetPaletteEntries将在PaletteLO上的最大可能范围为0到0xffff范围内工作。这将使我们能够覆盖位于PaletteLO上的0xffff限制内的所选存储位置,并且我们将能够通过调用SetPaletteEntries时传递的颜色参数来完全控制内容。

对于下一步的攻击,我们将创建另一个调色板,该调色板位于PaletteLO的上方。我们把它命名为PaletteHI。然后,我们将在PaletteLO上调用SetPaletteEntries,用我们选择的指针在PaletteHI的_PALOBJ内核结构中设置pFirstColor字段。由于pFirstColor表示调色板的颜色数组的基本地址,因此在PaletteHI上对SetPaletteEntries的后续调用将覆盖pFirstColor值所指向的内存,并完全控制其内容。至此,就可以调用PaletteHI上的SetPaletteEntries,我们已经获得了用任何选择的内容覆盖任何选择的内存位置的能力。

操作之前的调色板如下:

13.png

覆盖PalleteLO中的cEntries字段:

14.png

覆盖PaletteHI中的pFirstColor字段:

15.png

要查找调色板的内核地址,我们可以使用全局内核GDI表,该表保存有关每个GDI对象的信息,并以只读模式映射到每个正在运行的进程的用户地址空间。该表包含65536个条目。条目结构没有公开的文档,但是它通常被称为GDICELL:

16.png

GDICELL字段的含义如下:

KernelAddress:指向分配给对象的内核内存的指针;

ObjectOwnerPid:对象所属进程的PID;

Upper:对象32位句柄值的16位上半部分

ObjectType:表示对象类型的枚举

Flags:显然是一个包含一些标志的字段;

UserAddress:指向为对象分配的用户内存的指针;

要查找调色板的内核地址,只需使用调色板句柄值的16个最低位作为GDI表的索引,然后读取GDICELL.KernelAddress字段。

要创建在内核内存中足够接近的PaletteLO和PaletteHI调色板,只需在循环中创建调色板对象,直到所创建的任何两个调色板的位置满足我们的要求。当寻址0xffff限制内的条目时,PaletteLO必须能够覆盖PaletteHI的内核内存中的pFirstColor指针。不够,在实践中可以很容易地创建这样的调色板。

现在该说说完整的利用算法了:

1.确保从0x30000000到0x30ffffff的整个内存范围都是可写的,并用零填充。

2.创建一对足够接近的调色板:PaletteLO和PaletteHI。

3.分配一个空页面,并准备一个伪造的POOL_DESCRIPTOR。它的内容会导致覆盖PaletteLO的_PALOBJ内核结构中的cEntries字段。写入的值将是未知的,但保证至少是0x10000。

4.使用上述算法1查找并挂钩任何打印机驱动程序DLL,但不执行步骤8,挂钩驱动程序的DrvEnablePDEV函数。

5.调用gdi32.dll!EngCreatePalette创建一个包含256个条目的模板调色板,它将被称为PaletteSRC。

6.指示挂钩的DrvEnablePDEV函数返回PaletteSRC,以及ulNumColors参数等于514和在flGraphicsCaps字段中设置的GCAPS_PALMANAGED标志。

7.调用gdi32.dll!CreateDCA/W创建一个内部设备调色板,它的ppalThis字段指向某个0x30XXXXXX地址。这个设备面板将被称为PaletteDEVICE。PaletteSRC的参考计数器将变成1。

8.扫描内存范围从0x30000000到0x30ffffff的内存范围,并在其中找到伪造的用户模式_PALOBJ结构。

9.调用gdi32.dll!PaletteSRC的参考计数器将变为0,这允许我们在以后的步骤15中将其删除。

10.调用gdi32.dll!EngCreatePalette创建另一个模板调色板,这将称为PaletteHELPER。

11.指示挂钩的DrvEnablePDEV函数返回PaletteHELPER,这次,应在范围内的ulNumColors值中,在flGraphicsCaps字段中设置GCAPS_PALMANAGED标志。

12.调用 gdi32.dll!CreateDCA/W, PaletteHELPER的引用计数器将变为1,这正是我们所需要的。

13.在伪造的用户模式_PALOBJ结构中,将BaseObject字段中包含的句柄值设置为PaletteHELPER,还将ppalThis字段设置为指向用户模式_PALOBJ结构的开头。

14.在用户模式_PALOBJ结构之前准备一个伪造的池标头,在它上面也准备一个伪造的池标头。

15.在PaletteSRC上调用gdi32.dll!EngDeletePalette。由于PaletteSRC的_PALOBJ内核结构中的hSelected字段引用了PaletteDEVICE,因此PaletteDEVICE也将被删除。由于PaletteDEVICE的ppalThis指针指向用户内存中虚假的_PALOBJ结构,因此该用户地址将传递给win32k.sysExFreePoolWithTag。而且,由于我们在伪造的_PALOBJ之前和之后创建了伪造的pool header,所以我们的伪空页池描述符将由ExFreePoolWithTag使用。这样,PaletteLO的_PALOBJ内核结构中的cEntries字段将被一个至少为0x10000的值覆盖。

16.调用PaletteLO上的gdi32.dll!SetPaletteEntries,可以使用任意选定的地址覆盖PaletteHI的_PALOBJ内核结构中的pFirstColor指针。

17.调用 PaletteHI上的的gdi32.dll!SetPaletteEntries,可使用任何选定的值覆盖任何选定的地址。

我们现在有一个write-what-where原语,下面将描述如何选择覆盖的最终目标。

选择要覆盖的内存位置

访问令牌是包含进程或线程安全上下文的内核对象,这包括启动该进程的用户帐户的标识或该用户的线程和权限。当前,定义了34种可能的权限:

17.png

这些权限可能存在,也可能不存在。它们也可以被启用或禁用。令牌中存在的权限可能被禁用,然后重新启用。也可以将其删除,以使其不存在并且无法再出现,从而使进程无法提升其权限。仅在创建令牌期间才可以提供权限,并且创建令牌仅可用于拥有SeCreateTokenPrivilege和SeSecurityPrivilege的高权限系统进程。如果进程具有创建令牌的权限,则该进程可以创建具有所需权限的令牌,以后可以使用这些权限以任何用户身份启动进程。

要利用此漏洞,必须获取令牌结构的内核地址。为此,必须首先通过调用advapi32.dll!OpenProcessToken获得令牌的句柄。然后可以使用内部API ntdll.dll!NtQuerySystemInformation来获取令牌结构的内核地址。简化令牌的结构为:

18.png

Privileges_Present字段是一个64位的位字段,它决定了当前和不存在的权限。目前,只定义了2到35之间的权限,因此只有这些位是正常使用的。

Privileges_Enabled字段是一个64位的位字段,它确定启用哪些当前权限和禁用哪些当前权限。

为了提升权限,我们将PaletteHI的pFirstColor字段设置为指向TOKEN.Privileges_Present字段。然后,我们将在PaletteHI上调用gdi32.dll!SetPaletteEntries以写入索引从0到3的四个连续的调色板条目。这些调色板条目的新内容应包含所有设置为1的位。这将使所有权限都存在并启用。设置未定义的权限不会造成任何漏洞,尽管可以使用advapi32.dll!AdjustTokenPrivileges将其删除。

现在,我们拥有所有可能的权限,但是由于我们仍然是标准用户,因此仍然有些事情无法执行。下一步是利用我们现在拥有的SeCreateTokenPrivilege和SeSecurityPrivilege权限。使用这些权限,我们可以使用未公开的API ntdll.dll!NtCreateToken创建所需的任何令牌。实际上,我们可以创建一个表示具有所有权限的最强大SYSTEM用户的令牌,它是一个比通常的系统令牌更强大的令牌。操作系统本身使用系统令牌,该令牌没有某些权限。然后,拥有最强大的令牌以及SeAssignPrimaryTokenPrivilege权限,我们可以使用advapi32.dll!CreateProcessAsUserW创建可以存在的最强大的进程。

因为我们还有一个SeTcbPrivilege,所以我们可以更改新创建的令牌的SessionId字段。默认设置为0,因此使用此令牌创建的进程与系统服务一样工作,不能与桌面交互。将令牌的SessionId设置为某个登录用户的SessionId后,新创建的进程可以在用户的桌面上绘制窗口。对于演示目的来说,这样做很好,但是不需要捕获操作系统。

在64位系统上的漏洞利用

在64位系统上,palDst-> ppalThis指针是一个8字节的值。通过用0x30覆盖最高字节,我们将其设置为0x30XXXXXX’XXXXXXXX形式的值。当前64位体系结构的硬件实现仅支持48位寻址,虚拟地址的最高16位(位48至63)必须是位47的副本。因此,最高的16位必须为全0或全1。通过将最高字节设置为0x30,我们打破了此规则,这将导致异常并崩溃。这意味着在64位系统上,该漏洞只能用于DoS。

有可能利用这个漏洞来提高安装了Windows服务器的Itanium计算机上的权限。

Windows 8及更高版本中的变化

根据反汇编的win32k.sys(Windows 8和8.1)或win32kbase.sys(Windows 10),CreateSurfacePal函数中,该漏洞不存在。因为,用户模式传递的值可以被正确验证。

还值得注意的是,自Windows 10版本1607开始,GDICELL就开始了。KernelAddress字段不再保存指向内核内存的直接指针,你可以点此详细了解这部分内容。

补丁说明

微软在10月份解决了这个漏洞,并将该漏洞定义为 CVE-2019-1362。不过在漏洞修复中,微软只是通过“更正Windows内核模式驱动程序处理内存中对象的方式”方法解决了该漏洞。这个补丁很可能会将Windows 8的操作行为恢复到原来的版本,因为那个版本的操作系统没有受到影响。

总结

通过以上的讲解,很容易看出为什么这个漏洞为什么与众不同。

这些类型的漏洞通常与其他漏洞结合在一起,形成一个完整的漏洞链。最近,在针对韩国新闻网站的Chrome浏览器中,出现了类似的LPE和免费使用的Chrome浏览器。尽管LPE本身被认为没有严重的漏洞,但是与其他远程代码执行漏洞的结合会导致有效的攻击。

本文翻译自:https://www.thezdi.com/blog/2019/12/16/local-privilege-escalation-in-win32ksys-through-indexed-color-palettes如若转载,请注明原文地址: https://beta.4hou.com/vulnerable/22279.html
点赞 1
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论