深夜调试某浏览器内存损坏的小记录

0x00 引言

@瞌睡龙让俺仔细介绍一下，所以我就把之前文章http://drops.wooyun.org/papers/1020的一节的东西单独提出来了，之前百度浏览器5.0版本子窗口堆溢出的那版的程序我已经找不太到了，找到最接近的版本修复的只剩一个栈空间不足的问题而已了，这个小毛病我就搁在事后分析里面好了。

我找到的早期版本，比如4.5版，它的内存损坏和5.x的内存损坏效果类似，而且崩溃逻辑、位置都大体相同，5.x那个小报告中我提到的“低版本程序不测试直接转移到高版本”就是让这一个问题横跨几个世纪的主要原因。

当然，以下是我晚上几个小时调（口）试（胡）出来的，由于家里的电脑下WDK一直失败，所以没用上最新科技，只用了一个很老的windbg版本，有的地方还有些问题，所以我会粘来一点之前草稿里的数据，不过我确定这个对结果没有影响的。还有就是由于代码上班的时候调了一点，下班后回家继续调了后面的（俺是新开的例程），所以可能会有一些神推理名推测和超剧情发展的东西，这个请见谅。

由于代码实在太长，所以我会适当的标记出我在干什么，以及我想要得到什么结果，所以如果你看到了莫名其妙的黑色粗体标记，那肯定是我的注解。另外，由于这个windbg贴的代码本身实在已经是错综复杂了，所以我不会一句句的解释了，我会直接介绍函数在作甚，而且由于个人水平渣，写的时候卡壳了多次，所以这我已经预感到难免会出问题，这个也请大家见谅，各位发现不对的话请及时糊我熊脸！

0x01 基本需求

一个调试器是必要的，由于涉及事后调试和即时调试，俺就使用windbg来进行啦。由于目标程序是32位的，所以我选择了x86版的windbg。操作系统是Windows 7 sp1 简体中文版，说是oem但是看起来像盗版系统的系统。

然后就是几个基本的命令，t 步入，p 步过， gu 执行到返回，dd 查看dword， da 查看ansi， k 显示调用栈， poi 析取指针，等等，遇到新不明物种的话，windbg的F1里面的介绍是非常详尽的。

0x02 简单的事后分析（介绍）

事后分析我们就用百度浏览器5.0的一个栈内存不够分导致的Stack Buffer Overrun为例好了，poc还是那个，口胡我第一，那么开始呗。

0x02a 开始

首先，我们可以确定的是我们的poc可以导致这个程序崩溃，而通常我们的目标程序也会自带有一个dump文件，例如：

图：通常在%temp%下可能有崩溃文件，也有可能在%appdata%下

打开windbg，载入dump文件，进行简单的!analyze -v。显示信息如下：

The stored exception information can be accessed via .ecxr.
(51fc.a978): Stack overflow - code c00000fd (first/second chance not available)
eax=00000000 ebx=00000000 ecx=0046700c edx=0061e3e4 esi=000002a8 edi=00000000
eip=77a0f8d1 esp=0061bbe0 ebp=0061bc4c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!NtWaitForSingleObject+0x15:
77a0f8d1 83c404          add     esp,4
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

FAULTING_IP: 
browsercore+dbda7
033fbda7 8500            test    dword ptr [eax],eax

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 033fbda7 (browsercore+0x000dbda7)
   ExceptionCode: c00000fd (Stack overflow)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00522000

PROCESS_NAME:  baidubrowser.exe

ERROR_CODE: (NTSTATUS) 0xc00000fd - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xc00000fd - <Unable to get error code text>

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00522000

NTGLOBALFLAG:  0

FAULTING_THREAD:  0000a978

DEFAULT_BUCKET_ID:  STACK_OVERFLOW

PRIMARY_PROBLEM_CLASS:  STACK_OVERFLOW

BUGCHECK_STR:  APPLICATION_FAULT_STACK_OVERFLOW_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 045b7a85 to 033fbda7

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
0061e2a8 045b7a85 0061e3e4 0061e634 00000001 browsercore+0xdbda7
0061e2c4 0337100c 0061e3e4 0061e634 0061e7f4 browsercore+0x1297a85
0061e620 03333292 0061e7f4 00000000 00000000 browsercore+0x5100c
……（略）
0061fe88 001e63bf 00100000 00000000 00352318 baidubrowser+0x65da
0061ff18 7703336a 7efde000 0061ff64 77a29f72 baidubrowser+0xe63bf
0061ff24 77a29f72 7efde000 2a534886 00000000 kernel32!BaseThreadInitThunk+0xe
0061ff64 77a29f45 001e6412 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0061ff7c 00000000 001e6412 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  ~0s; .ecxr ; kb

FOLLOWUP_IP: 
browsercore+dbda7
033fbda7 8500            test    dword ptr [eax],eax

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  browsercore+dbda7

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: browsercore

IMAGE_NAME:  browsercore.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  526f3e67

FAILURE_BUCKET_ID:  STACK_OVERFLOW_c00000fd_browsercore.dll!Unknown

BUCKET_ID:  APPLICATION_FAULT_STACK_OVERFLOW_INVALID_POINTER_READ_browsercore+dbda7

WATSON_IBUCKET:  2118667

WATSON_IBUCKETTABLE:  17

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/baidubrowser_exe/2_210_0_42889/526f3e61/browsercore_dll/10_0_0_17/526f3e67/c00000fd/000dbda7.htm?Retriage=1

Followup: MachineOwner
---------

我们可以由上得到很多重要的信息：

例如最上层的调用栈、BUCKET信息（分类漏洞）、出错的位置、出错的语句、它并没有对这个异常的处理程序等等，还有最重要的信息：我们根本没它的符号，淦。

0x01b 查看崩溃附近的数据

好在它没有做什么其他的事儿，我们查看faulting ip附近的代码即可知道他为什么会崩。

FAULTING_IP: 
browsercore+dbda7
033fbda7 8500            test    dword ptr [eax],eax

执行

uf browsercore+dbda7

得到：

0:000> uf browsercore+dbda7
Unable to load image C:\Program Files (x86)\baidu\BaiduBrowser\browsercore.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for browsercore.dll
*** ERROR: Module load completed but symbols could not be loaded for browsercore.dll
browsercore+0xdbd94:
033fbd94 3bc8            cmp     ecx,eax
033fbd96 720a            jb      browsercore+0xdbda2 (033fbda2)

browsercore+0xdbd98:
033fbd98 8bc1            mov     eax,ecx
033fbd9a 59              pop     ecx
033fbd9b 94              xchg    eax,esp
033fbd9c 8b00            mov     eax,dword ptr [eax]
033fbd9e 890424          mov     dword ptr [esp],eax
033fbda1 c3              ret

browsercore+0xdbda2:
033fbda2 2d00100000      sub     eax,1000h

browsercore+0xdbda7:
033fbda7 8500            test    dword ptr [eax],eax  ；崩溃在此
033fbda9 ebe9            jmp     browsercore+0xdbd94 (033fbd94)

但是这是什么？看起来为什么这么像__alloca_probe的验证代码？对比一下实实在在的__alloca_probe看来是没跑了。

__alloca_probe:
push           ecx
cmp            eax,1000h
lea            ecx,[esp+8]
jb             lastpage
probepages:
sub            ecx,1000h
sub            eax,1000h
test           dword ptr [ecx],eax
cmp            eax,1000h
jae            probepages 
lastpage:
sub            ecx,eax
mov            eax,esp
test           dword ptr [ecx],eax
mov            esp,ecx
mov            ecx,dword ptr [eax]
mov            eax,dword ptr [eax+4]
push           eax
Ret

崩在了最后的栈校验上。查看一下完整的调用栈，使用~*kvn查看所有线程的调用栈：

0:000> ~*kvn

.  0  Id: 51fc.a978 Suspend: 0 Teb: 7efdd000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 0061bbe0 76fa149d 000002a8 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 (FPO: [3,0,0])
01 0061bc4c 77031194 000002a8 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98 (FPO: [SEH])
02 0061bc64 77031148 000002a8 ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75 (FPO: [3,0,4])
03 0061bc78 001056c7 000002a8 ffffffff 006e9948 kernel32!WaitForSingleObject+0x12 (FPO: [2,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
04 0061dd78 00105467 ac68c25f 0010542d 7710030c baidubrowser+0x56c7
05 0061dda0 7706fffb 0061de58 ac7abd84 00000000 baidubrowser+0x5467
06 0061de28 77a674ff 0061de58 77a673dc 00000000 kernel32!UnhandledExceptionFilter+0x127 (FPO: [SEH])
07 0061de30 77a673dc 00000000 0061ff64 77a1c550 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
08 0061de44 77a67281 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
09 0061de6c 77a4b499 fffffffe 0061ff54 0061dfa8 ntdll!_except_handler4+0x8e (FPO: [4,5,4])
0a 0061de90 77a4b46b 0061df58 0061ff54 0061dfa8 ntdll!ExecuteHandler2+0x26 (FPO: [Uses EBP] [5,3,1])
0b 0061deb4 77a4b40e 0061df58 0061ff54 0061dfa8 ntdll!ExecuteHandler+0x24 (FPO: [5,0,3])
0c 0061df40 77a00133 0061df58 0061dfa8 0061df58 ntdll!RtlDispatchException+0x127 (FPO: [2,25,4])
0d 0061df40 033fbda7 0061df58 0061dfa8 0061df58 ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0061dfa8)
0e 0061e2a8 045b7a85 0061e3e4 0061e634 00000001 browsercore+0xdbda7
0f 0061e2c4 0337100c 0061e3e4 0061e634 0061e7f4 browsercore+0x1297a85
10 0061e620 03333292 0061e7f4 00000000 00000000 browsercore+0x5100c
11 0061e814 048b515c 0061e82c fffffffa 00000200 browsercore+0x13292
12 0061e854 03334634 02ec7d94 02ec2780 02ec2780 browsercore+0x159515c
13 0061e974 046e67c9 02ec7d94 02ec7d94 02e63c30 browsercore+0x14634

   1  Id: 51fc.9920 Suspend: 1 Teb: 7efda000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 02aff61c 76fa15e9 00000003 02aff66c 00000001 ntdll!ZwWaitForMultipleObjects+0x15 (FPO: [5,0,0])
01 02aff6b8 770319fc 02aff66c 02aff6e0 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x100 (FPO: [SEH])
02 02aff700 770341d8 00000003 7efde000 00000000 kernel32!WaitForMultipleObjectsExImplementation+0xe0 (FPO: [5,8,4])

…………blablabla

然后我们可以很开心的看到：

0:000> ~*kvn

.  0  Id: 51fc.a978 Suspend: 0 Teb: 7efdd000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 0061bbe0 76fa149d 000002a8 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 (FPO: [3,0,0])
01 0061bc4c 77031194 000002a8 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98 (FPO: [SEH])
02 0061bc64 77031148 000002a8 ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75 (FPO: [3,0,4])
03 0061bc78 001056c7 000002a8 ffffffff 006e9948 kernel32!WaitForSingleObject+0x12 (FPO: [2,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
04 0061dd78 00105467 ac68c25f 0010542d 7710030c baidubrowser+0x56c7
05 0061dda0 7706fffb 0061de58 ac7abd84 00000000 baidubrowser+0x5467
06 0061de28 77a674ff 0061de58 77a673dc 00000000 kernel32!UnhandledExceptionFilter+0x127 (FPO: [SEH])
07 0061de30 77a673dc 00000000 0061ff64 77a1c550 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
08 0061de44 77a67281 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
09 0061de6c 77a4b499 fffffffe 0061ff54 0061dfa8 ntdll!_except_handler4+0x8e (FPO: [4,5,4])
0a 0061de90 77a4b46b 0061df58 0061ff54 0061dfa8 ntdll!ExecuteHandler2+0x26 (FPO: [Uses EBP] [5,3,1])
0b 0061deb4 77a4b40e 0061df58 0061ff54 0061dfa8 ntdll!ExecuteHandler+0x24 (FPO: [5,0,3])
0c 0061df40 77a00133 0061df58 0061dfa8 0061df58 ntdll!RtlDispatchException+0x127 (FPO: [2,25,4])
0d 0061df40 033fbda7 0061df58 0061dfa8 0061df58 ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0061dfa8)
0e 0061e2a8 045b7a85 0061e3e4 0061e634 00000001 browsercore+0xdbda7
0f 0061e2c4 0337100c 0061e3e4 0061e634 0061e7f4 browsercore+0x1297a85

我们看看它的上层函数做了什么：

0:000> uf 045b7a85
No code found, aborting

居然显示没有代码，看来事后调试已经满足不了我们了，不过既然跑到了_alloca_probe，那真相就只有一个了！对，在栈上分配的东西太大了，比栈还大，比栈还牛逼，于是栈不干了，结果就抛个异常罢工了。

这只是一个小演示而已，反正我们没符号，反正我们没代码，但是我们有PoC，我们需要的是实时调试，下面进入正题。

0x04 试验

试验环境：

1&2、VS2010，Debug+Release，也就是分别看看文中的malloc(0)会弄出什么情况。
3&4、gcc，Debug+Release查看malloc(0)是什么情况。
所谓正确的实践是检验真理的唯一标准，我们分别看看会产生什么问题。
注：以下都是从调试器直接启动的，堆是调试器友好的。

0x04a 直观的编译、运行

1、VC2010 Debug + malloc（0）

返回了一个非NULL的堆。

损坏。

2、 VC2010 Release + malloc（0）

情形类似

HEAP[testMalloc.exe]: Heap block at 005455B8 modified at 005455C1 past requested size of 1 Windows 已在 testMalloc.exe 中触发一个断点。

其原因可能是内存损坏，这说明 testMalloc.exe 中或它所加载的任何 DLL 中有 Bug。

原因也可能是用户在 testMalloc.exe 具有焦点时按下了 F12。

输出窗口可能提供了更多诊断信息。程序“[4256] testMalloc.exe: 本机”已退出，返回值为 0 (0x0)。

3、gcc Debug+malloc（0）

分配了一个非NULL但是可以释放的堆。

成功覆盖了堆的信息

同样崩溃

4、gcc Release+malloc（0）

情形类似

果不其然四个情况下都表明：VS和G++编译器编译后malloc(0)返回的不是NULL，而是一个活生生的堆，而且你动它一下，它就赖地上让你赔钱了。

0x04b 具体发生了什么？

虽然和浏览器堆破坏的这一例不一样，但是为了演示一下malloc(0)分配的内存到底为何不能操作，我们还是使用VC2010+Relase+malloc(0) 32位环境下的程序来试试看吧：

0x04b.1 编译源程序

我们模拟一下那个创建小窗口前的一些准备工作：

// testMalloc.cpp : 定义控制台应用程序的入口点。
//

#include "stdafx.h"
#include <stdlib.h>
#include <string>
#include <windows.h>

#define URL_LENGTH 26

int _tmain(int argc, _TCHAR* argv[])
{
    TCHAR * test = (TCHAR *)malloc(0); //很不幸，这儿的参数是0
    memset(test, 0x11 , URL_LENGTH); //为了方便查看，我把改成了0x11

    TCHAR url[27] = _T("ABCDEFGHIJKLMNOPQRSTUVWXYZ"); 
    //正好26字,假设我们的url就是这个拉

    int i = WideCharToMultiByte(CP_ACP, 0, url, -1, NULL, 0, 0,FALSE); 
    char * szTmp = new char[i];
    WideCharToMultiByte(CP_ACP, 0, url, -1, szTmp, i, 0, FALSE);

    memcpy(test, szTmp, i); //复制到我们的堆中

    free(test);

    return 0;
}

0x04b.2 载入windbg中：

在wmain处下断点，l-t之后并用p执行完malloc，然后查看当前分配来的堆的信息：

可以看到当前的堆内数据如下，其中数据使用了堆的填充模式abababe8 abababab，而这看起来像是一个已分配的堆空间的末尾的填充模式（为什么呢？因为如果分配了字节的话，堆会用baadf00d这个填充模式来填充将来可能会被使用的空间，而这个abababe8 blablabla则是像是这个填充模式的末尾，或者，更像是说ANSI字符串的中止符号“”的东西）：

这是memset完，我们26个字符填充进去之后的效果：

这个相当于什么？相当于在一个堆的用户可操作区域之外做写入操作，这样数据就已然超出了堆的申请大小，让它活生生的演变成了堆溢出，之后程序还会对它进行free，必然是错上加错。

0x04b.3 证明我们的想法

让我们换一点代码，我们把malloc(0)修改为malloc(27)，重新载入。

这回，我们看到了一个新的填充模式，baadf00d ，而这正是我们之前提到的可用但是未初始化的堆空间的填充模式。

而如此如此运行之后，程序正常退出。

0x04c 几个小名词

调试友好

当在调试器下启动进程的时候，堆管理器将修改所有新堆的请求，并且设置创建标志，用于启用“调试友好”的堆，这会应用到内存里面所有堆，包括默认的进程堆，这种堆与原先的最大的差异是堆块中包含了额外的“填充模式”区域，这个区域位于用户可访问的部分之后，堆管理器通过这个区域来确认堆的完整性。如果这个填充模式被修改了，堆管理器会立刻中断进入调试器内。

堆管理器在分配堆时自动的使用某个填充模式来初始化某片内存，填充模式的内容取决于堆块的状态，当堆块最初被返回给调用者时，堆管理器将使用填充模式来填充堆块中用户可访问的部分，其中在填充模式中包含的值就是baadf00d，这表示这个堆块虽然分配成功，但是没有初始化。如果有程序在没有初始化堆块之前就对其进行解引用操作，就会产生一个存取违例的异常；如果程序正确的初始化了堆块，那么程序将继续执行，这个堆块被释放后，堆管理器将再次对堆块中用户可以访问的部分进行填充，使用的值是feeefeee。设置完这些个填充模式之后，调试器将通过检测这个填充模式的值是否被修改，来跟踪在释放后堆块上所发生的访问操作。

__alloca_probe

这个函数在栈上分配空间，超过0x1000的每次按0x1000的大小（如果剩余未分配的大小大于0x1000的话）不断在栈上分配内存(sub ecx,1000h; sub eax,1000h; test [ecx],eax; ecx是之前参数在栈中的地址，这样可以检测是否真的分配上了0x1000字节)，test [ecx],eax用来检查是否栈已经不够用了（栈的大小是固定的，所以如果分配的地址取不到的话[ecx]就会存取违例了），如果已经撑爆了通常会报告“Stack Overrun”（也会看到Stack Overflow）的报警。

当应用程序启动时，程序的cookie（4字节（dword），无符号整型）被计算出来（伪随机数）并保存在加载模块的.data节中,在函数的开头这个cookie被拷贝到栈中，位于EBP和返回地址的正前方（位于返回地址和局部变量的中间）。

[buffer][cookie][savedEBP][savedEIP]

在函数的结尾处，程序会把这个cookie和保存在.data节中的cookie进行比较。
如果不相等，就说明进程栈被破坏，进程必须被终止。

为了尽量减少额外的代码行对性能带来的影响，只有当一个函数中包含字符串缓冲区或使用_alloca函数在栈上分配空间的时候编译器才在栈中保存cookie。另外，当缓冲区至少于5个字节时，在栈中也不保存cookie。

在典型的缓冲区溢出中，栈上的返回地址会被数据所覆盖，但在返回地址被覆盖之前，cookie早已经被覆盖了，因此就导致了exploit的失效（但仍然可以导致拒绝服务），因为在函数的结尾程序会发现cookie 已经被破坏，接着应用程序会被结束。

BUCKET

微软分类崩溃类型，用一系列牛逼算法所生成并使用的一个标识符号。

0x05 修复

官方是修复了，不过纵观全局他这代码也太粗心了，俺的最大的建议就是每个返回值都检查一遍，千万别嫌麻烦……

0x06 参考资料

Mario Heweardt, Daniel Pravat 《windows高级调试》

http://bbs.pediy.com/archive/index.php?t-126858.html

http://msdn.microsoft.com/en-us/library/ee480951.aspx

安全研究