复现环境

• 系统：windows11
• target：adobe reader 9.3.4版本
• 调试器：Immunity Debugger
• 反汇编器：IDA Pro

因为是分析调试漏洞，所以就在win11里面搞了。要实际利用，winxp应该可以

有时间再看看winxp里面是咋利用拿shell的:->

漏洞分析

漏洞点是栈溢出，介绍下怎么去定位到这个漏洞点，目录位置如下

​cve-2010-2883_adobe_reader_9_3_4\Reader\CoolType.dll​

将这个dll文件放入到ida里面，是32位的

具体怎么找到他呢，网上的教程是让搜SING的字符串，再用交叉应用去定位

​​

​

定位到这里之后，跟着往下走就能看到strcat​，这里就是溢出的地方

​

1
2
3
4
5
6
7
8
9
10
11

char *strcat(char *dest, const char *src);

DESCRIPTION
The strcat() function appends the src string to the dest string, overwriting the terminating null byte ('\0') at the end of dest,
       and then adds a terminating null byte.  The strings may not overlap, and the dest string must have enough space for  the  result.
       If  dest  is not large enough, program behavior is unpredictable; buffer overruns are a favorite avenue for attacking secure pro‐
       grams.

strcat() 函数将 src 字符串附加到 dest 字符串，覆盖 dest 末尾的终止空字节 ('\0')，
        然后添加一个终止空字节。 字符串不能重叠，并且目标字符串必须有足够的空间用于结果。
        如果 dest 不够大，程序行为是不可预测的； 缓冲区溢出是攻击安全程序的最佳途径。

​

Destination是一个局部变量，src没有限制好长度，就会造成溢出

• reader 如何解析pdf文件，造成了src过长，是分析的重点

1. 先用msf生成一份exp.pdf文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

msf6 > search cve-2010-2883

Matching Modules
================

   #  Name                                            Disclosure Date  Rank   Check  Description
   -  ----                                            ---------------  ----   -----  -----------
   0  exploit/windows/browser/adobe_cooltype_sing     2010-09-07       great  No     Adobe CoolType SING Table "uniqueName" Stack Buffer Overflow
   1  exploit/windows/fileformat/adobe_cooltype_sing  2010-09-07       great  No     Adobe CoolType SING Table "uniqueName" Stack Buffer Overflow


Interact with a module by name or index. For example info 1, use 1 or use exploit/windows/fileformat/adobe_cooltype_sing

msf6 > use 1
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp

先搜索一下cve的exploit，然后选择第1个

‍

1
2
3
4
5

msf6 exploit(windows/fileformat/adobe_cooltype_sing) > set payload windows/exec
payload => windows/exec
msf6 exploit(windows/fileformat/adobe_cooltype_sing) > set CMD calc.exe
CMD => calc.exe
msf6 exploit(windows/fileformat/adobe_cooltype_sing) >

然后设置下对应exp的功能，虽然在我win11上不能达到利用的效果，还是设一下

‍

1
2
3
4

msf6 exploit(windows/fileformat/adobe_cooltype_sing) > exploit

[*] Creating 'msf.pdf' file...
[+] msf.pdf stored at /home/cynault/.msf4/local/msf.pdf

​exploit​命令生成pdf文件

‍

2. 分析这个pdf文件

这里漏洞是reader在解析字体时出现的，所以需要分析里面的TTF文件，用PdfStreamDumper提取PDF里面的TTF文件

PdfStreamDumper下载地址

‍

​

在对应的Object里面找到这个SING字符，应该就是说明这个就是TTF obj了

obj里面的对象10，右键点击选择 Save Decompressed Streams保存文件到本地

有意思的是dump下来的文件比pdf要大，这里我猜ttf文件在pdf里面编码压缩过的，把这个文件放到Imhex里面我看到了在调试过程中会看到的字节0x0c0c0c0c​

​​

‍

​

每一个表都有一个TableEntry的结构,TableEntry结构如下，

里面的char tag[4] = “SING”，可以通过这个来定位

和上图相对，offset为0x11c，也就是说后面SING表数据的起始地址为0x11c

1
2
3
4
5
6

typedef struct_SING{
    char tag[4]; //标记
    ULONG checkSum; //校验和
    ULONG offset; //相对文件的偏移
    ULONG length; //数据长度
} TableEntry

‍

SING表的数据结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

typedef struct
{
    USHORT  tableVersionMajor; 
    USHORT  tableVersionMinor;
    USHORT  glyphletVersion;
    USHORT  embeddinginfo;
    USHORT  mainGID;
    USHORT  unitsPerEm;
    SHORT   vertAdvance;
    SHORT   vertOrigin;
    BYTE[28]    uniqueName; //长度为28字节
    BYTE[16]    METAMD5;
    BYTE    nameLength;
    BYTE[]  baseGlyphName;
} SINGTable;

strcat 函数从SINGTable.uniqueName开始复制数据到栈上，直到遇到NULL，strcat本来就是危险函数还用，不过是10年前了。vs2019现在默认都不能用了。

uniqueName前面的数据都是short类型 16位 2字节，一共8个就是0x10字节，所以从0x11C+0x10 = 0x12c开始就是uniqueName数据，之后在调试过程中关注进行栈溢出的数据是不是这些数据就行了

​​

‍

调试流程

1. 对strcat函数下断点

用Immdbg打开文件并运行，这样CoolType.dll才会加载进入来

​​

进入可执行模块

计算偏移: （ps:上面看到的基址不是真正代码开始的基址+0x1000才是）

基址地址-0x79a01000 PE文件基址-0x08001000 strcat函数地址-0x0803DDAB

0x79a01000 - 0x08001000 + 0x0803DDAB

1
2

Python>0x79a01000 - 0x08001000 + 0x0803DDAB
0x79a3ddab

​bp 0x79a3ddab​ 下断点

2. 运行跟踪程序

将准备好的exp.pdf丢进Reader里面

程序断在strcat处

​​​​​​

记录栈信息和栈调用情况

​0x010fdea8​-dest存储为将要输入进数据的stack地址0x010fdf18​。这个地址是ebp现在存放的地址，直接往栈帧底部输数据我是没想到他是啥想法，关键是dest完全没有在ida中看到的260buffer怎么大，稍微输点数据进来就炸了。

​​​​​

​0x010fdf18​关注这个地址的数据内容变化

​​

步过strcat函数，因为是往0x010fdf18​输入的，所以栈顶不会变，就不看了

​​

​​

和Imhex里面的对比下，可以发现他将SINGTable.uniqueName的数据读进来了

​​

程序会在0x0c0c0c00c0c0c中崩溃，我这东西实在是难跟踪，主要他不是在执行strcat函数的那个函数的ret中崩的，是在跳进别的函数里面，甚至不是在CoolType.dll里面崩的，最后跳进另一个dll里面，真奇怪~