对国产OFD软件阅读器的漏洞挖掘与分析

近期研究了下国内特有的ofd版式阅读器，这款阅读器针对国内ofd文件阅读开发而来，而ofd文件是由工业和信息化部软件司牵头中国电子技术标准化研究院成立的版式编写组制定的版式文档国家标准，在国家标准全文公开系统上也可以查到，如下：

但是ofd文件在民用领域推广力度相对不足，安全研究这块也相对较少，因此大概率还是存在不少问题的，因此针对ofd版式阅读器windows平台的软件进行了研究，下面说下针对这款软件的漏洞挖掘与分析过程。

动态漏洞挖掘
动态漏洞挖掘主要是通过fuzzing工具对程序进行漏洞挖掘，当然也会配合ida等工具进行静态分析。针对文档类型的程序，在windows平台上主要通过winafl这款工具进行fuzz，其它工具如honggfuzz、peach等和winafl相比双方各有优劣，也尝试过在linux平台利用模拟器对windows应用进行黑盒漏洞挖掘，但是有大量的问题需要解决，目前该方案并不成熟。如果对文档格式了解不深的话，使用winafl可能是漏洞挖掘产出最快的方式之一，下面说下利用winafl进行漏洞挖掘的基本流程。

准备
winafl、dynamorio、procmon、ida、study-pe、x64dbg

SuwellReader.exe（1.6.6.29）

测试环境：win10 1909 64位

pdf文件漏洞挖掘过程
寻找fuzzing所需的函数偏移

具体参考winafl官方说明。这里说明下，前段时间ofd阅读器对进行了大规模更新，整体框架发生了较大变化，这里分析的是之前的版本，新版本后边会介绍。

在使用过程中发现该程序可以打开pdf、ofd、sfd等文件，由于pdf的样本比较容易获取，因此先针对pdf格式进行漏洞挖掘。

先看下程序的目录，大概可以确定SuwellReader.exe是主程序，由于没有发现其它处理文件相关的开源库，配合一些分析基本可以确定它将库代码和主程序一起打包为一个程序，因此这里没办法针对特定的组件编写harness来进行针对性的fuzzing，直接分析这个程序即可，windows上使用procmon或者火绒剑可以很方便的观测程序的宏观行为如读写文件，如下：

由于程序会多次创建、读取文件，因此需要额外的进行分析来进一步确定fuzz所需的函数偏移。由于程序中的大量函数内部并没有将ebp作为函数栈帧，同时函数调用时采用虚表调用的方式，因此静态与动态分析函数调用栈时都比较麻烦，难以形成一个完整的函数调用栈，需要一步步去调试分析。同时这里建议选择的函数尽量接近调用栈底部，这样能最大可能保证输入文件被程序解析完全，尽可能多的覆盖程序的解析文件逻辑，提高fuzzing所需的程序覆盖率。当然如果发现fuzzing速度非常低的话，就需要更改下函数偏移了，不然的话很难产生有效的变异，如何取舍就看后面fuzzing的效果了。

寻找关闭文件句柄的函数偏移
因为程序在打开一个文件后并不会主动关闭文件句柄，因此需要手动去在特定的位置关闭文件句柄。这里需要两个函数偏移，一个位于程序创建后面读文件所需的文件句柄的函数尾部，在这个函数中可以拿到需要关闭的文件句柄，另一个位于程序完全读取文件后的某个函数尾部，这个函数偏移相对宽泛，可以直接选择上一步的fuzzing所需的函数偏移，在那个函数尾部调用对应的api关闭文件句柄即可，如下：

利用winafl的debug模式进行测试

命令如下：

drrun.exe -c winafl.dll -debug -target_module SuwellReader.exe -target_offset 0x195b30 -call_convention fastcall -nargs 2 -fuzz_iterations 10 – C:\target\shuke\Suwell\Reader_Pro\SuwellReader.exe C:\fuzztools\manul\input\PDFBOX-1074-1.pdf
这里使用了最新版的dynamorio并重新编译了winafl，但是这里存在一个性能方面的问题，新版的dynamorio在windows上的性能表现似乎和旧版的存在一定差距，这个性能方面的问题也是后期才发现的，后面会进行说明。

运行看起来没有什么问题，如下：

这里为了确认fuzzing一个循环所需的时间，特地修改了winafl.dll，添加了计时函数，可以看出fuzzing一个循环的时间还是很长的，因此后面fuzzing的整体速度会非常慢。

pdf样本获取

可以采用网络上公开的fuzzing样本集或者用爬虫从百度、google等搜索引擎批量爬取，当然还可以使用libfuzzer、honggfuzz等工具对开源的pdf程序进行fuzzing，将触发新覆盖率的文件保存作为种子在windows平台上进行测试。

样本裁剪

利用winafl自带的python脚本winafl-cmin.py对样本进行裁剪，筛选出能够尽可能多的触发更多程序代码路径的样本,将无法触发新路径的样本进行过滤。

正式fuzzing

使用如下命令：

afl-fuzz.exe -i in -o out -t 20000 -m none -D C:\fuzz\fuzz_tools\dyn\dyn\bin32\ -M fuzz1 – -covtype bb -call_convention fastcall -target_module SuwellReader.exe -target_offset 0x195b30 -coverage_module SuwellReader.exe -fuzz_iterations 50000 -nargs 2 – C:\fuzz\fuzz_tools\Reader_Pro\SuwellReader.exe @@
效果如下：

虽说有crash，但是后面分析了下是由于提前关闭文件句柄导致，因此需要重新patch程序。可以看出速度确实非常慢，和之前利用debug模式测试的速度基本一致，需要两到3秒钟才能完成一次循环。而且由于变异过程中可能产生程序无法识别的样例，导致程序弹出打开文件失败的对话框，这样就必须找到弹出对话框的大概位置，将相关的代码进行patch。还有一种情况是生成了带密码的pdf文件，这样打开文件的时候还会弹窗需要用户输入密码，针对这类需要用户交互的行为都必须修改程序的逻辑，这样才能保证fuzzing的正常运行。但是这同样也会带来其它风险，比如由于patch代码导致的程序出现crash，因此在分析crash时最好使用原版程序进