+0x008 KernelStack : Uint4B +0x00c InitialStack : Uint4B +0x010 ActualLimit : Uint4B 一旦用户模式回调完成后，系统调用ntcallbackreturn函数，修正堆栈后跳回 KeUserModeCallback,完成调用以回到内核中继续执行。此函数拷贝回调函数的结果到原内 核栈，并根据kernel_control结构中保存的信息恢复原陷阱栈（PrevTrapFrame)以 及内核栈。在」測口回先前离开的地址即的nt!kicallusermode位置之前，系统会清除内核调用 栈。总而言之，&0&111186^(^6函数的整个调用过程如下：nt!KeUserModeCallback -> nt! KiCallUserMode -> nt! KiServiceExit -> ntdll!KiUserCallbackDispatcher -> 回调函数-> int2B -> nt!KiCallbackReturn -> nt!KeUserModeCallback，即ring0->ring3->ring0的过程，在堆栈准备完毕后，使用kiserviceExit函数回到4叩3，然 后选择函数KiUserCallbackDispatcher，从peb中取出kernelcallbacktable的基址，再以 apinumber为索引在此表中查找对应的回调函数并调用，调用完之后int28触发 nt!KiCallbackReturn使其再次进入内核，修正堆栈后跳回keusermodecallback完成调用。 由于递归或嵌套的回调可能会导致内核栈无限制的增长，或者创建任意数量的栈，对于 每个运行的线程内核会使用线程对象结构体的成员变量kethhead->callbackdepth跟踪回调 深度。在每次回调发生后，系统会将线程栈上使用的字节数即栈基地址减去栈顶指针值，加到callbackdepth变量上，~^&内核尝试创建一个新堆栈，nt! KiMigrateToNewKernelStack 函数会确保callbackdepth变量值不超过0xc000，否者返回一个status stack overflow码。 2.使用用户模式回调机制实施内核攻击 本小节我们将给出一些攻击手法，使得&461^可以借助用户模式回调机制实施特权提 升攻击，在开始详细讨论每种攻击手法之前，首先分析下用户模式回调函数机制是如何操纵 用户关键段。 2.1Win32命名规范 windows管理器使用关键段和全局锁机制管理重要的内部系统结构。用户模式回调机制 允许应用程序挂起如1子系统，且射032^总是会在回调机制进入到用户模式执行用户命令时， 离开关键段，此时Win32k可能正在执行其它的任务。当回调函数返回时，即在执行权返回到 内核时，win32k会重新进入到关键段。我们可以在任何一个调用KeUserModeCallback的函数中观察到此行为，如下代码所示： call _UserSessionSwitchLeaveCrit@0 lea eax, [ebp+var_4] push eax lea eax, [ebp+var_8] push eax push 0 push 0 push 43h call ds:_ _irap_KeUserModeCallback@20 cal1 UserEnterUserCritSec@0 从用户模式回调函数返回时，Win32k必须确保相关的对象与数据结构还保存在例外状态 中。在执行权限交给回调函数时，代码的执行已经脱离了关键段，此时用户模式代码可自由 该表一些对象的属性、重新分配数组空间等等。例如，回调函数可以调用SetParent()该表 父类窗口指针；若系统在调用回调函数之前，事先保存了父窗口的索引指针，则系统返回到 内核继续执行时，若内核没有进行一定的校验或执行对象锁，那么可能会带来一定的安全漏 为了确保应用程序开发者不会利用此漏洞，win32k使用了自己特有的函数命名规范。如： 函数的前缀命名为“xxx”或“zzz”完全依赖于系统是如何调用一个用户模式回调。大多数 情况下，使用“xxx”前缀的函数会在调用一个用户模式回调时，离开关键段资源。然而， 某些情形下，函数可能需要一套特殊的参数以便转入到回调函数真实被调用的路径分支上。 这就是为何我们有时会看到不带前缀的函数调用xxx函数，因为它们提供给xxx函数的参数无 法导致一个回调函数被真实调用；而一般情况下，前缀为“ZZZ”的函数总是调用异步或者 延迟的回调函数。典型的案例如一些窗口事件可能因为某种原因不需要及时处理，如定时器 设置等。此时，win32k会调用xxxFlushDeferredWindowEvents函数刷新事件队列。但重要的 是，调用zzz函数时，必须需要确保在调用xxxWindowEvent函数时，win32k ! gdwDeferWinEvent的变量不会空，否则回调函数会立即处理。 Win32k的命名规范缺乏一致性。Win32k内的一些函数虽然调用了回调函数，但并不有标 记。具有原由不是太清楚，但一个可能的解释是，随着时间的推移一些函数在命名规则上没 有做更新。相应地，开发者可能会认为这类函数不会调用回调函数，故回避了一些必要的验 证（如对象是否上锁、指针值校验等）。从MSll-034给出的安全补丁看，一些函数的命名已 经做了更新处理，部分更新的函数如下： |
