本部分将对常见的二进制漏洞做系统分析，方便在漏洞挖掘过程中定位识别是什么类型漏洞，工欲善其事，必先利其器。

栈溢出漏洞属于缓冲区漏洞的一种，实例如下：

编译后使用windbg运行

直接运行到了地址0x41414141，这个就是字符串AAAA，就是变量str里面的字符串通过strcpy拷贝到栈空间时，没有对字符串长度做限制，导致了栈溢出，最后覆盖到了返回地址，造成程序崩溃。

溢出后的栈空间布局如下：

栈溢出原理图

使用以下代码演示堆溢出漏洞

由于调试堆和常态堆的结构不同，在演示代码中加入getchar函数，用于暂停进程，方便运行heapoverflowexe后用调试器附加进程。debug版本和Release版本实际运行的进程中各个内存结构和分配过程也不同，因此测试的时候应该编译成release版本。

运行程序，使用windbg附加调试（一定要附加调试），g运行后程序崩溃

上面的ecx已经被AAAA字符串覆盖掉了，最后在引用该地址的时候导致崩溃，通过前面的栈回溯定位到了main函数入口，找到复制字符串的函数下断点

此时堆块已经分配完毕，对应的分配地址位于0x007104a0，0x007104a0是堆块数据的起始地址，并非堆头信息的起始地址，对于已经分配的堆块，开头有8字节的HEAP_ENTRY结构，因此heap的HEAP_ENTRY结构位于0x007104a0-8=0x710498。

在windbg上查看两个堆块的信息，这两个堆块目前处于占用状态，共有0x10大小空间

在windbg中，使用！heap查看HeapCreate创建的整个堆块信息，可以发现堆块heap后面还有一个空闲堆块0x007104c0：

在复制字符串的时候，原本只有0x10大小的堆块，填充过多的字符串的时候就会覆盖到下方的空闲堆块007104c0，在复制前007104c0空闲堆块的HEAP_FREE_ENTRY结构数据如下：

覆盖后0x007104c0空闲块的HEAP_FREE_ENTRY结构数据如下：

整个空闲堆头信息都被覆盖了，包括最后的空闲链表中的前后向指针都被成了0x41414141，后面调用HeapFree释放堆块的时候，就会将buf2和后面的空闲堆块0x007104c0合并，修改两个空闲堆块的前后向指针就会引用0x41414141，最后造成崩溃。

如果把上面释放堆块的操作换成分配堆块HeapAlloc（），也会导致崩溃，因为在分配堆块的时候会去遍历空闲链表指针，会造成地址引用异常，当内存中已经分配多个堆块的时候，可能覆盖到的就是已经分配到的堆块，此时可能就是覆盖HEAP_ENTRY结构，而不是HEAP_FREE_ENTRY结构。

堆溢出原理图

微软提供了一些调试选项用于辅助堆调试，可以通过windbg提供的gflag.exe或者！gflag命令来设置：

对heapoverflow.exe添加堆尾检查和页堆，去掉堆标志：

主要是在每个堆块的尾部，用户数据之后添加8字节，通常是连续的2个0xabababab，该数据段被破坏就可能发生了溢出。

对heapoverflow.exe开启hpc和htc，用windbg加载对heapoverflow程序，附加进程无法在堆尾添加额外标志，使用以下命令开启堆尾检查和堆参数检查：

执行命令g后，按下回车键程序会断下来

上面一句调试输出信息的意思是，在大小为0x10的堆块0x001E0498的0x001E04B0覆盖破坏了，0x10大小的空间加上堆头的8字节一共0x18字节，0x001E04B0-0x001E0498=0x18，也就是说0x001E04B0位于堆块数据的最后一个字节上，基于上面的信息，可以分析出程序主要是因为向0x10的堆块中复制过多数据导致的堆溢出。

在调试漏洞的时候，经常需要定位导致漏洞的代码和函数，比如导致堆溢出的字节复制指令rep movsz等，前面的堆尾检查方式主要是堆被破坏的场景，不利于定位导致漏洞的代码。为此。引入了页堆的概念，开启后，会在堆块中增加不可访问的栅栏页，溢出覆盖到栅栏页就会触发异常。

开启页堆：

用windbg加载heapoverflow，运行！gflag命令开启了页堆，然后g运行后在cmd按下回车键断下

可以发现程序在复制A字符串的时候触发了异常，程序复制到0x11字节的时候被断下，此时异常还未破坏到堆块，直接定位导致溢出的复制指令rep movs

根据栈回溯，调用rep movs的上一层函数位于image00400000+0x1084的上一条指令，也就是00401322，此处调用了00401000函数，很容易发现这是主入口函数：

整数分为有符号和无符号两类，有符号数以最高位作为符号位，正整数最高位为1，负整数最高位为0，不同类型的整数在内存中有不同的取值范围，unsigned int = 4字节，int = 4字节，当存储的数值超过该类型整数的最大值就会发生溢出。

在一些有符号和无符号转换的过程中最有可能发生整数溢出漏洞。

基于栈的整数溢出的例子：

代码中size变量是无符号短整型，取值范围是0~65535，输入的值大于65535就会发生溢出，最后得到size为4，这样会通过边界检查，但是用memcpy复制数据的时候，使用的是int类型的参数i，这个值是输入的65540，就会发生栈溢出：

基于堆的整数溢出的例子：

代码中的size是unsigned short int类型，当输入小于5，size减去5会得到负数，但由于unsigned short int取值范围的限制无法识别负数，得到正数65533，最后分配得到过大的堆块，溢出覆盖了后面的堆管理结构：

格式化漏洞产生的原因主要是对用户输入的内容没有做过滤，有些输入数据都是作为参数传递给某些执行格式化操作的函数的，比如：printf，fprintf，vprintf，sprintf。

恶意用户可以使用%s和%x等格式符，从堆栈和其他内存位置输出数据，也可以使用格式符%n向任意地址写入数据，配合printf（）函数就可以向任意地址写入被格式化的字节数，可能导致任意代码执行，或者读取敏感数据。

以下面的代码为例讲解格式化字符串漏洞原理：

可以发现当输入数据包含%s和%x格式符的时候，会意外输出其他数据：

用ollydbg附加调试程序，执行前需要先设置命令行参数，调试-参数-命令行：test-%x

在运行程序后，传递给printf的参数只有test-%x，但是他把输入参数test-%x之后的另一个栈上数据当做参数传给了printf函数，因为printf基本类型是：

传递给printf的参数只有一个，但是程序默认将栈上的下一个数据作为参数传递给了printf函数，刚好下一个数据是strcpy（）函数的目标地址，就是buff变量，buff刚好指向test-%x的地址0x0019fec4，所以程序会输出0x0019fec4，如果后面再加一个%x就会将src参数的值也输出了，这样就可以遍历整个栈上数据了。

除了利用%x读取栈上数据，还可以用%n写入数据修改返回地址来实现漏洞利用。

Double Free漏洞是由于对同一块内存进行二次释放导致的，利用漏洞可以执行任意代码，编译成release示例代码如下：

在二次释放p2的时候就会发生程序崩溃，但是并不是每次出现Double Free都会发生崩溃，要有堆块合并的动作发生才会发生崩溃

双重释放原理图

在释放过程中，邻近的已经释放的堆块存在合并操作，这会改变原有堆头信息，之后再对其地址引用释放就会发生访问异常。

通过以下代码理解UAF漏洞原理：

buf2 “占坑”了buf1 的内存位置，经过UAF后，buf2被成功篡改了

程序通过分配和buf1大小相同的堆块buf2实现占坑，似的buf2分配到已经释放的buf1内存位置，但由于buf1指针依然有效，并且指向的内存数据是不可预测的，可能被堆管理器回收，也可能被其他数据占用填充，buf1指针称为悬挂指针，借助悬挂指针buf1将内存赋值为hack，导致buf2也被篡改为hack。

如果原有的漏洞程序引用到悬挂指针指向的数据用于执行指令，就会导致任意代码执行。

在通常的浏览器UAF漏洞中，都是某个C++对象被释放后重引用，假设程序存在UAF的漏洞，有个悬挂指针指向test对象，要实现漏洞利用，通过占坑方式覆盖test对象的虚表指针，虚表指针指向虚函数存放地址，现在让其指向恶意构造的shellcode，当程序再次引用到test对象就会导致任意代码执行。

UAF漏洞利用原理图

先区分一下数组越界漏洞和溢出漏洞：数组越界访问包含读写类型，溢出属于数据写入；部分溢出漏洞本质确实就是数组越界漏洞。

数组越界就像是倒水的时候倒错了杯子，溢出就像是水从杯子里溢出来。

下面代码为例分析数组越界访问漏洞：

执行生成的程序，然后分别输入12345，输出结果如上，当输入的数组下标分别是12的时候，会得到正常数值，但是从索引3开始就超出了原来的数组array的范围，比如输入5，就会数组越界访问array数组，导致读取不在程序控制范围内的数值。

使用ollydbg调试发现array[5]就是从array开始的第六个数据0x4012A9，已经读取到了array之外的数据，如果越界访问距离过大，就会访问到不可访问的内存空间，导致程序崩溃。

类型混淆漏洞（Type Confusion）一般是将数据类型A当做数据类型B来解析引用，这就可能导致非法访问数据从而执行任意代码，比如将Unit转成了String，将类对象转成数据结构。

类型混淆漏洞是现在浏览器漏洞挖掘的主流漏洞，这类漏洞在java，js等弱类型语言中非常常见。

下面的代码，A类被混淆成B类，就可能导致私有域被外部访问到：

以IE/Edge类型混淆漏洞（CVE-2017-0037）为例讲解，漏洞原因是函数处理时，没有对对象类型进行严格检查，导致类型混淆。

PoC如下：在PoC中定义了一个table，标签中定义了表id为th1，在boom()中引用，然后是setInterval设定事件。

运行PoC，用Windbg附加并加载运行出现崩溃

从崩溃点可以看到eax作为指针，引用了一个无效地址，导致崩溃，而上一条指令是一个call，这个无效的返回值来自这个call，在这个call处下断点，ecx作为参数，存放的对象是一个Layout::FlowItem::`vftable虚表

这里读取虚表中+4的值，为0时this指针赋值v1，随后v1+16后返回，因此，Layout::FlowItem::`vftable所属指针的这个情况是正常的，函数会正常返回进入后续处理逻辑

让程序继续运行，会再次调用该函数，此时ecx并不是一个虚表对象，而是一个int Array对象，这里我们可以通过条件断点来跟踪两个对象的创建过程，重点关注两个对象创建的函数，一个是FlowItem::`vftable对应的虚表对象，另一个是引发崩溃的int Array对象。这两个函数的返回值，也就是eax寄存器中存放的指向这两个创建对象的指针。

通过跟踪可以看到第一次调用Readable函数时ecx是一个正常的FlowItem对象，而第二次调用的时候ecx是一个int Array Object。Layout::Patchable >::Readable函数是处理虚表对象的函数，由于boom()函数中引用th1.align导致Readable函数得到第二次引用，由于没有进行对象属性检查，导致第二次调用时将table对象传入，最终发生类型混淆崩溃。

竞争条件（Race Condition）是由于多个线程/对象/进程同时操作同一资源，导致系统执行违背原有逻辑设定的行为，这类漏洞在linux，内核层面非常多见，在windows和web层面也存在。

互斥锁的出现就是为了解决此类漏洞问题，保证某一对象在特定资源访问时，其他对象不能操作此资源。

比如如下代码：

执行结果如下：

按照我们的预想，结果应该都是10，但是发现结果可能存在非预期解，原因就在于我们没有对变量COUNT做同步制约，导致可能Thread-7在读COUNT,还没来得及更改COUNT,Thread-8抢夺资源，也来读COUNT,并且将COUNT修改为它读的结果+1，由此出现非预期。

《漏洞战争》

https://www.jianshu.com/p/bb3aaf3f5890

http://v0w.top/2018/08/16/条件竞争/

个人github博客地址：

https://github.com/streetleague/0xbird.github.io/

个人安全研究公众号平台：