微软 Demoting leads to use after free 漏洞原理分析

漏洞描述

微软8月份补丁日发布了编号为CVE-2024-38147的DWM核心漏洞库提权漏洞，由山石网科信创安全实验室报告，目前已修复完成，漏洞详细情况详如下：

微软 DirectComposition 合成器是一个 Windows 组件内核组件，位于win32k驱动程序中，它支持高性能的位图合成，具有变换、效果和动画功能。应用程序开发人员可以使用 DirectComposition API 创建视觉上引人入胜的用户界面，该界面具有从一个视觉到另一个视觉的丰富流畅的动画过渡。DirectComposition 通过实现高帧速率、使用图形硬件和独立于 UI 线程运行来实现丰富流畅的过渡。DirectComposition 可以接受由不同渲染库绘制的位图内容，包括 Microsoft DirectX 位图和渲染到窗口的位图（HWND 位图）。此外，DirectComposition 支持各种变换，例如 2D 仿射变换和 3D 透视变换，以及剪裁和不透明度等基本效果。

该模块在2019年-2022年期间爆出过大量的漏洞尤其是 CInteractionTrackerBindingManagerMarshaler 跟踪器对象绑定关联管理器对象中。我们在上一篇的漏洞分析文章中已经详细分析了CVE-2024-38059 漏洞的产生原因和一些背景信息，详细见：Self Destruction To Use After Free In Kernel：CVE-2024-38059分析记录 。这里我们将更加详细的介绍出现漏洞的 CInteractionTracker 对象。

漏洞分析

我们首先了解一下 CInteractionTracker。InteractionTracker类处理输入 ExpressionAnimation 中的目标，通常用于跟踪输入驱动视觉效果的运动。InteractionTracker 10586 SDK 版本中被引入到 Windows.UI.Composition.Interactions 命名空间。InteractionTracker 可实现以下功能：

完全灵活 – 自定义和定制操作体验的各个方面；使用 InteractionTracker 构建自定义操作体验时，你需要的所有旋钮都可供您使用。

流畅的性能 – 操作体验面临的挑战之一是其性能取决于 UI 线程。当 UI 繁忙时，这可能会对任何操作体验产生负面影响。InteractionTracker 的构建旨在利用新的动画引擎，该引擎以 60 FPS 的速度在独立线程上运行，从而实现流畅的动作。

这里可能理解起来有点抽象，我们可以看看下面的windows的案例动画：

图：自定义操作的窗口动画效果(来源MSDN)

我们可以感受到这里窗口动画的丝滑及流畅，这个是传统windows sdk无法做到的效果，也就不难理解为什么需要 InteractionTracker 对象了。

在 DWM 中，InteractionTracker 类由 CInteractionTracker 对象实现，你可以将多个 CInteractionTracker 对象绑定到一个 CInteractionTrackerBindingManager 对象上。CInteractionTrackerBindingManager 维护一个 CInteractionTracker 对象的二元关系哈希表，该表也称为连接轴(Axis)。一个 CInteractionTracker 对象可以连接到除其自身之外的任何其他 CInteractionTracker对象，也就是多个组合起来的动画跟踪器。个人分析后觉得这里二元关系代表运动轨迹的两个坐标x和y，同时也符合之前对CInteractionTrackerBindingManager 对象的分析。

InteractionTracker 对象一共具有四种状态：

空闲：没有活动输入或动画驱动InteractionTracker 对象

交互：活动用户输入正在驱动 InteractionTracker 对象

惯性：活动动画是由活动输入或程序速度产生，驱动 InteractionTracker 对象，这里翻译我们并不确定是否是微软原本的意图。

自定义动画：InteractionTracker 的属性正在直接进行动画处理，也就是绑定的Animation对象，这些对象基本上都是ExpressionAnimation的子类，因为这类复杂的线性/非线性动画需要由专业的高等数学公式进行支持，我们在逆向的时候就发现了相关的复杂数学函数代码。

下面的图是该对象的状态机器：

图：InteractionTracker状态机(来源MSDN)

你可以在msdn上找到更多信息：InteractionTracker Class

CInteractionTrackerBindingManager::ProcessSetTrackerBindingMode 函数负责构建两个 CInteractionTracker 对象的二元关系，逻辑如下：

1. 获取两个 CInteractionTracker 对象指针

2. 调用 CInteractionTrackerBindingManager::BringBoundTrackersStateInSync 函数将第一个 CInteractionTracker 对象及其绑定的跟踪器的状态与第二个 CInteractionTracker 对象的状态同步。比如第一个对象的状态是Idle，第二个是CustomAnimation，那么就都同步为Idle，防止混乱

3. 调用 CInteractionTrackerBindingManager::BringBoundTrackersPositionAndScaleInSync 函数将两个 CInteractionTracker 对象的位置等属性进行同步
   

4. 调用 CInteractionTrackerBindingManager::AddOrUpdateTrackerBindings 函数来添加新的二元关系哈希表或者更新现有的二元绑定关系。

漏洞存在于第二步，我们来看一下详细信息：

CInteractionTrackerBindingManager::BringBoundTrackersStateInSync 函数执行以下步骤：

1. 获取第一个 CInteractionTracker 对象的所有连接的跟踪器（也是 CInteractionTracker 对象）并将它们插入 xtree 中以避免重复。它还获取与第一个 CInteractionTracker 对象连接的带动画的跟踪器（我们在下文中称之为主跟踪器）

2. 获取第二个 CInteractionTracker 对象的所有连接的跟踪器和主跟踪器，然后将它们插入到 xtree 中以避免重复。

3. 如果第一个和第二个 CInteractionTracker 对象位于同一轴上(Axis)，则该函数将不执行任何操作，直接返回

4. 如果不在一个轴上，停止并清空第二个 CInteractionTracker 对象的自定义、默认、交互和任何其他动画对象。

5. 如果第二个 CInteractionTracker 对象有一个主跟踪器，并且该跟踪器上绑定了动画，它将调用 CInteractionTracker::DemoteToBoundTracker 函数来停止并清空跟踪器上绑定的动画。我们猜测每个轴只能有一个主跟踪器，如果另外一个轴已经有主跟踪器，则该轴上的主跟踪器则将被降级为正常绑定的边界跟踪器，这里的主跟踪器上就是绑定Animation动画对象的跟踪器，从程序逻辑中不难得出一个轴上只能绑定一个动画，且绑定在主跟踪器上，其他都是辅助的跟踪器，如果一个轴有多个主跟踪器，就会出问题

6. 如果第一个 CInteractionTracker 对象的状态与第二个 CInteractionTracker 对象的状态不同，则该函数将尝试调用 CInteractionTracker::SetState 函数，以将第二个 CInteractionTracker 对象轴上的所有 CInteractionTracker 对象的状态更改为第一个 CInteractionTracker 对象的状态(Idle, Inertia, Interacting, CustomAnimation)，此步骤函数将遍历第二步中生成的 xtree ，也就是第二个对象连接的其他跟踪器。我们可以理解为，在一个轴上(Axis)，所有的 CInteractionTracker 对象状态都必须相同，改变了轴上的一个对象状态其他对象状态都必须进行同步修改。

然而在某些特殊情况下，我们可以在一个轴上绑定多个主跟踪器，因此在第二步中我们可以得到一个包含一个或多个主跟踪器对象的 xtree 。而在第六步中，CInteractionTracker::SetState 函数可以将主跟踪器对象的状态从 CustomAnimation(3) 更改为 Idle(0)，随后的操作将其降级为绑定跟踪器，但是在降级时候并没有清除跟踪器中的动画指针，也没有将跟踪器指针从动画指针的通知对象数组中清除。此操作非常危险！因为它直接将跟踪器状态从 CustomAnimation(3) 更改为 Idle(0)，但动画指针仍然存在于主跟踪器中，同时动画对象仍在其通知对象数组中保存了主跟踪器的指针。当攻击者尝试将另一个不同的自定义比例动画对象绑定到主跟踪器时，CInteractionTracker::TransitionToCustomAnimation 函数将直接覆盖旧的动画对象指针，而不会清空它并停止旧的动画，因为主跟踪器的状态为 Idle，函数默认这个状态下跟踪器中是没有绑定任何动画对象的。因此，我们销毁了主跟踪器及其绑定对象之后，我们将得到这样一个动画对象：在其通知对象数组中保存一个已经释放的 CInteractionTracker 指针并且没有被清除，后面针对该动画通知对象的任何操作都会触发UAF。

CInteractionTracker::TransitionToCustomAnimation 函数中的代码通过在改变调用对象的状态后调用 CInteractionTrackerBindingManager::UpdateBoundTrackerState 函数来解决这个问题，不过很可惜的是仍然不能阻止我们将状态从 CustomAnimation(3) 更改为 Idle(0)并且保留动画指针于跟踪器对象中。

我们看看漏洞位置的具体代码：

void __fastcall CInteractionTrackerBindingManager::UpdateBoundTrackerState(__int64 a1, __int64 a2, int a3){  // ...  // 1. 获取所有连接在当前 CInteractionTracker 对象上所有轴上的连接Tracker对象并放入 xtree 中  CInteractionTrackerBindingManager::GetConnectedTrackersForAxis(a1, a2, 7u, (__int64)v11, 0i64);  v9 = *(_QWORD *)v11[0];  v12 = *(_QWORD *)v11[0];
  // 2. 遍历 xtree   while ( !*(_BYTE *)(v9 + 25) )  {    v10 = *(_QWORD *)(v9 + 32);    // 3. 不改变当前对象状态    if ( v10 != a2 )    {      // 4. 如果当前Tracker是主连接器，即有动画绑定, 将其降级为普通的边界追踪器      if ( (*(_BYTE *)(v10 + 541) & 1) != 0 )        CInteractionTracker::DemoteToBoundTracker(*(_QWORD *)(v9 + 32), a3 == 3);      // 5. 将一个连接对象的状态进行同步      CInteractionTracker::SetState(v10, a3, 1);      if ( *(_DWORD *)(v10 + 504) )        *(_BYTE *)(*(_QWORD *)(v10 + 480) + 24i64 * (unsigned int)(*(_DWORD *)(v10 + 504) - 1) + 20) = 1;    }
    // 6. 遍历下一个Tracker对象    std::_Tree_unchecked_const_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<void * const,`anonymous namespace'::_Mutex_count_pair>>>,std::_Iterator_base0>::operator++((__int64)&v12);    v9 = v12;  }  // ...}
void __fastcall CInteractionTracker::DemoteToBoundTracker(__int64 this, char a2){  // ...  v2 = *(_BYTE *)(this + 541);  // 1. 如果该跟踪器有绑定任何动画对象则进入  if ( (v2 & 1) != 0 )  {    *(_BYTE *)(this + 541) = v2 & 0xFE;    CInteractionTracker::DestroyInteractionAnimations(this);    CInteractionTracker::DestroyDefaultAnimations(this, 0);    LOBYTE(v5) = a2;
    // 2. 尝试清空并解绑位置动画    CInteractionTracker::StopCustomAnimation(this, 0, v5);
    // 3. 尝试清空缩放动画并解绑    if ( *(_QWORD *)(this + 360) )    {      if ( (*(_BYTE *)(this + 541) & 2) == 0 )      {        LOBYTE(v6) = a2;        CInteractionTracker::StopCustomAnimation(this, 1, v6);      }    }  }}

我们假设一个名为 C1 的跟踪器之前绑定一个主跟踪器，如果我们尝试在 C1 的任何其他连接跟踪器上设置动画对象，该函数将调用 CInteractionTrackerBindingManager::UpdateBoundTrackerState 函数将所有连接的跟踪器放入 xtree 中，然后遍历它以找到 C1 的主跟踪器，然后将其降级为绑定跟踪器，确保只有一个主跟踪器连接在轴上，同时一个轴上也只能绑定一个动画对象( ExpressionAnimation 或者其他 Expression 对象)。设置动画对象的跟踪器将成为新的主跟踪器。但是在 CInteractionTracker::DemoteToBoundTracker 函数中存在一个问题。我们可以看到，如果一个跟踪器具有缩放动画但是它已经设置了位置，该函数将不会停止缩放动画(ScaleAnimation)，但是该函数会停止位置动画(PositionAnimation)并清空动画指针和该位置动画对象通知数组中的 CInteractionTracker 指针，这非常奇怪。这意味着跟踪器已降级，但内部仍有缩放动画指针保留，会导致UAF漏洞。

我们看看如何复现该漏洞，这个漏洞的poc复现步骤比较复杂，主要步骤如下：

1. 创建 CInteractionTrackerBindingManager 对象

2. 创建两个 CInjectionAnimationMarshaler 对象

3. 创建一个 CManipulationMarshaler 和 CInteractionMarshaler 对象，以后会使用，主要是用作 CInteractionTracker 对象内部状态转移时候使用的

4. 创建7个 CInteractionTrackerMarshaler 对象（我们分别称它们为 C1、C2、C3、C5、C7）

5. 调用 CInteractionTrackerBindingManagerMarshaler 的 SetBufferProperty 函数将 C1 与 C2、C3 绑定在一起并调用 CommitChannel 函数。关系表为 C1 ：[(C1, C2), (C1, C3)]，C2 ：[(C2, C1)]，C3 ：[(C3, C1)]，两个连接对象之间都会互相建立关系表，现在这个轴仍然没有主跟踪器

6. 在 C1 上调用 SetReferenceProperty，绑定第一个 CInjectionAnimationMarshaler 对象，设置C1的缩放动画，然后调用 CommitChannel 函数。Dwm 将调用 CInteractionTracker::ProcessSetRequestedScaleAnimation 函数，该函数还将调用 CInteractionTrackerBindingManager::UpdateBoundTrackerState 函数来同步轴上 CInteractionTracker 对象的状态，因为轴上没有主跟踪器，所以 C1 将成为主跟踪器

7. 在 C1 上调用 SetIntegerProperty 函数来设置请求的位置和相关的flag并调用 CommitChannel 函数，这样我们就可以绕过 CInteractionTracker::DemoteToBoundTracker 函数中的检查在接下来步骤中

8. 在 C2 上调用 SetReferenceProperty，绑定第二个 CInjectionAnimationMarshaler 对象，然后调用 CommitChannel 函数。由于 C1 和 C2 现在位于同一轴上（C1、C2、C3 位于同一轴上），CInteractionTrackerBindingManager::UpdateBoundTrackerState 函数将遍历树并发现 C1 是主跟踪器，并尝试将其降级，但 C1 设置过了position，因此 CInteractionTracker::DemoteToBoundTracker 函数不会清空 C1 中的缩放动画指针，C2 将成为主跟踪器

9. 在 CInteractionTrackerBindingManagerMarshaler 上调用 SetBufferProperty 来绑定 C5 和 C2，并调用 CommitChannel 函数。C5 是新对象，不属于任何轴，C1、C2、C3 在同一轴上。Dwm 将调用 CInteractionTrackerBindingManager::BringBoundTrackersStateInSync 函数并获取 C5 的连接跟踪器，但此时 xtree 只包含 C5 本身。C2 的连接跟踪器是 C1、C3，主跟踪器是 C2。并且该函数将尝试停止 C2 的默认动画、位置动画和任何其他动画，然后将 C2 降级为绑定跟踪器。因为 C2 将与 C5 绑定，此时主跟踪器在另一个轴上。然后该函数将遍历 C2 的连接跟踪器树（C1 和 C2）并同步 C5 的状态（空闲）。所以在这个步骤中，C1 和 C2 是空闲的，C1 中的缩放动画指针仍然保留

10. 在 C1 上调用 SetReferenceProperty，绑定第二个 CInjectionAnimationMarshaler，然后调用 CommitChannel 函数。我们将修改 C1 的老的ScaleAnimation 指针，但是此时状态为Idle，我们没有将C1从老的ScaleAnimation 通知数组中删除，导致后面的UAF漏洞

11. 在 CInteractionTrackerBindingManagerMarshaler 上调用 SetBufferProperty 来解除 C5 和 C2、C1 和 C2、C1 和 C3 的绑定并调用 CommitChannel 函数

12. 调用 CInteractionTrackerBindingManagerMarshaler、C1、C2、C3 和 C5 上的 Releaseresource 函数，然后调用 CommitChannel 函数。现在第一个 CInjectionAnimationMarshaler 对象在通知程序数组中保存 C1 的释放指针。我们可以使用此指针触发 UAF，上面两个步骤主要是释放所有的 CInteractionTrackerMarshaler 对象

13. 在 C7 上调用 SetBufferProperty 来绑定在步骤 3 中创建的 C7 上的 CManipulationMarshaler 和 CInteractionMarshaler。C7 将被注册到 CManipulationMarshaler 的通知程序数组中

14. 在 CManipulationMarshaler 对象上调用 SetBufferProperty，DWM 将调用 CManipulation::Update 函数通知 C7 对象。然后 DWM 将调用 CInteractionTracker::OnChanged 函数将 Active Manipulation 添加到 C7 的交互源管理器中。我们需要这一步来将 C7 转入交互模式(Interacting)

15. 调用 Sleep 一段时间，而 DWM 渲染线程会调用 InteractionSourceManager::UpdateActiveManipulations 函数。DWM 最终会调用 CInteractionTracker::TransitionToInContact 函数将 C7 状态从 Idle 转换为 Interacting

16. 在 C7 上调用 SetReferenceProperty，绑定第一个 CInjectionAnimationMarshaler，由于现在 C7 状态为 Interacting，不能直接转为 CustomAnimation 模式（你可以在 MSDN 上查看状态机的调用状态），所以 CInteractionTracker::SetCustomAnimation 函数会返回 0，表示没有动画绑定到 C7。然后 dwm 会调用 CBaseExpression::NotifyAnimationCompleted 函数将第一个 CInjectionAnimationMarshaler 对象添加到 CExpressionManager 的动画数组中

17. 调用 Sleep 一段时间，而 DWM 渲染线程调用 CBaseExpression::NotifyAnimationStateChanged 函数来通知第一个 CInjectionAnimationMarshaler 对象的通知程序，UAF发生并且 DWM 崩溃

漏洞利用

下面内容均为技术交流探讨分享，请勿用于非法用途！

如何利用该漏洞呢？

首先考虑控制整个对象的内容，这里我们推荐一个可以分配几乎任意大小（小于0x1000）内存并且可以控制其中内容的地方：

仍然是 CInteractionTracker 对象，其中的 CInteractionTracker::ProcessSetInertiaModifierAnimations 函数中在堆上分配了一个空间，这个空间大小和内容都可控，我们可以通过该函数将之前释放的对象重新分配回来，这里传入的大小为0xa4，为数组数量，最终分配的大小为0x290，而被释放的 CInteractionTracker 对象大小为0x288，测试发现最终会进行大小对齐，如果我们传入0xa2在win32kbase.sys层面会进行大小对其检查，不会调用成功，所以只能传0xa4，还需要注意的是，DWM 使用 Low Fragmentation Heap (LFH) 管理堆空间，我们需要大量分配才能将之前释放掉的内存地址重新分配回来，有分配空间地址保护，这里我们选择创建0x500个 CInteractionTracker 对象，在poc创建对象时候同时创建这些用来进行堆分配的对象，可以发现我们成功的分配回被释放的 CInteractionTracker 对象，在测试时候我发现分配这个数量后基本上都能控制之前被释放的对象内容：

这里我们已经成功的控制了被释放对象中的内容，下面就是构造其虚表地址和参数内容进行代码执行了。

到了这里我们有两种方案，主要解决的问题是虚表摆放的位置，我们可以通过我之前我们发现的 DWM 信息泄漏漏洞，泄漏堆地址，随后摆放虚表，然后达到让 DWM 加载我们的恶意 DLL 并得到高权限的shell或者是 DWM 进程内的任意代码执行权限。或者我们可以不需要信息泄漏，寻找一个在 DLL 全局变量中保存的一个函数地址，这个函数可以进行寄存器内容的迁移，因为这里如果要加载 DLL，LoadLibrary 的第一个参数路径和虚表函数重叠，所以不能直接调用这个函数，同时也要考虑 XFG 保护的问题，由于时间的关系，编写文章时笔者已经在去往Las Vegas Black Hat的路上，这样的函数大家可以做一个练习寻找一下。

我们使用之前的漏洞进行信息泄漏，是今年三月份修复的漏洞，DWM 往攻击者和其建立的共享内存之间越界写入内存后的空间值，详细见公共号文章：Windows DWM 核心库信息泄露漏洞 (CVE-2024-26172) 复现分析。通过该漏洞我们泄漏了对象所在的地址空间并覆盖成我们这次在 Vegas 讨论的存在于 combase.dll 中的一个可以过 XFG 检查的函数，并且这个函数内部调用了 LoadLibraryExW 函数，可以直接加载我们的DLL，从而 GetShell 成功，这个技巧我们也在今年 DEF CON 32 会议中分享过，详细见我们今年的议题内容。

我们可以成功加载我们的恶意DLL并弹出shell，加载DLL的函数我们选择combase.dll中的 ImmediateCallback__lambda_eebf69f5a3250f8786ebc7c3378db176___::CallbackFunction 函数，可以看到这个函数内部调用了 LoadLibraryExW 函数，同时做了寄存器的迁移，虚表开始的位置我们可以选择摆放我们的加载 DLL 路径，后面+0x48偏移放置该函数，这个函数可以过 XFG 检查：

下面图是虚表的布局，详细可以见DEF CON 32 山石网科的议题介绍：

当然这里还没有结束，DWM 弹出的 shell 权限仍然不是最高的权限，该进程没有 SeDebugPrivilege，SeImpersonatePrivilege，同时 Token 也不是 System 用户，更不在 Administrator 用户组中，这里也有一个办法，在谷歌去年分析的 CVE-2023-36033 在野漏洞报告中，CVE-2023-36033: Windows DWM Core Library Elevation of Privilege Vulnerability 。其实这个攻击面也是当时我们研究的点，并且也是山石网科安全技术研究院在2021年发现的一个漏洞变种，可以看其文章的参考来源。大致思路是使用 Shutdown /l 命令执行关机，其实这个命令应该是完成注销功能，会有一个 System 进程和 DWM 进程进行交互，是 LogonUI.exe ，这个进程使用了标准的 DWM 通信方法，应该是在其创建某些对象的时候是放在共享内存中的，我们可以通过在 DWM 进程内修改这些进程的虚表来进行提权操作？谷歌的报告其实分析的也不是很详细，等笔者 Vegas 回来之后再好好分析，总之这里也提供一个利用的思路，是完全可以通过该漏洞获取 System Shell 的。

再次提醒，以上内容均为技术交流探讨分享，请勿用于非法用途！

影响版本

Windows 10 Version 21H2 for 32-bit Systems

Windows 10 Version 21H2 for ARM64-based Systems

Windows 10 Version 21H2 for x64-based Systems

Windows 10 Version 22H2 for 32-bit Systems

Windows 10 Version 22H2 for ARM64-based Systems 

Windows 10 Version 22H2 for x64-based Systems

Windows 11 version 21H2 for ARM64-based Systems

Windows 11 version 21H2 for x64-based Systems

Windows 11 Version 22H2 for ARM64-based Systems

Windows 11 Version 22H2 for x64-based Systems

Windows 11 Version 23H2 for ARM64-based Systems

Windows 11 Version 23H2 for x64-based Systems

Windows 11 Version 24H2 for ARM64-based Systems

Windows 11 Version 24H2 for x64-based Systems

Windows Server 2022

Windows Server 2022 (Server Core installation)

Windows Server 2022, 23H2 Edition (Server Core installation)

安全建议

安装相应的补丁程序，目前，官方已发布修复程序，受影响的用户可以直接升级至安全版本。

下载地址：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38147

参考信息

1. https://learn.microsoft.com/en-us/uwp/api/windows.ui.composition.interactions.interactiontracker?view=winrt-22621

2. https://learn.microsoft.com/en-us/windows/uwp/composition/interaction-tracker-manipulations

3. https://conference.hitb.org/hitbsecconf2023ams/session/hunting-windows-desktop-window-manager-bugs/

4. https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2023/CVE-2023-36033.html

5. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38147

6. https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20WangJunJie%20Zhang%20YiSheng%20He%20-%20Defeating%20magic%20by%20magic%20Using%20ALPC%20security%20features%20to%20compromise%20RPC%20services.pdf

原文始发于微信公众号（山石网科安全技术研究院）：微软 Demoting leads to use after free 漏洞原理分析