由CVE-2018-12831引发的一些思考

漏洞分析

0x00 : 前言

这是一个很奇怪的case，在我还在学校的时候对Adobe Reader日常逆向的时候意外发现的一个UAF漏洞，很不幸的是无法利用；但是有趣的是他的触发方式，在后面的工作中，我在Foxit中意外发现了类似的问题，就在昨天，Adobe更新最新补丁之后，也发现了一个类似的UAF(0day,已提交给厂商)，这个0day不在本文讨论范围之内。

0x01 : 漏洞情况

漏洞的基本信息如下:
1
Adobe Acrobat and Reader versions 2018.011.20063 and earlier, 2017.011.30102 and earlier, and 2015.006.30452 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution.

是一个很鸡肋的UseAfterFree的鸡肋漏洞，我个人认为无法利用 :(

这个漏洞发现的很意外，算是无心插柳，我们都知道可以使用vbs脚本调用一些windows的api，然后去完成一些窗口操作，下面来看一下这段vbs脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
REM: Save a Pdf as JPEG.
 REM:Also Multipage PDF will can be changed. Then every page will be saved as single JPEG
 REM: The Filename you can change to your needs.
 REM: If you use Drag&drop or Filename as command
 REM: line argument the script will work with this file.

'*********Settings in File**************************
FileNM = "C:\Users\muhe\Desktop\x.pdf" '//Filename for File to transfer if NO argument is given
'****************************************************

set WshShell = CreateObject ("Wscript.Shell")
set fs = CreateObject("Scripting.FileSystemObject")
Set objArgs = WScript.Arguments
if objArgs.Count = 1 then FileNM = ObjArgs(0)
Info = "Save as JPEG"&VbCr&_
       "File Name: "&FileNM &vbCr&" Delete existing JPEG FILES with the same Name before!"&vbcr&" Start now?"
OK = MsgBox(Info, vbQuestion+vbYesNo,"Insert Files") : if OK = vbNo then WScript.quit

'//Start or switch to Acrobat
WshShell.run "Acrobat.exe"
While not WshShell.AppActivate("Adobe Acrobat") : Wscript.Sleep 1000 : Wend
Set gApp = CreateObject("AcroExch.App")

if not fs.FileExists(FILENM) then
     MsgBox "Ups! " & FileNM & " doesn't exist? " & "Try new!", vbExclamation
     WScript.quit
end if

Set BASFL = CreateObject("AcroExch.pdDoc")
OK = BASFL.Open(FileNM) '//Open the PDF-File
if not OK Then if MsgBox("Error open Basic File") then Wscript.quit
BASFL.OpenAVDoc(mid(FileNM,InstrRev(FileNM,"\")+1)) '// get the PDF-File into view
WScript.Sleep 1000

'// to get this part working reliable(!) use WinAPI, WMI, or AutoITX.dll to check the forground window

WshShell.SendKeys "^+s" '// send keys for SaveAs
WScript.Sleep 1000
WshShell.SendKeys "{tab}" '// goto Filetype
WScript.Sleep 500
WshShell.SendKeys "J" '// switch filetype zu JPEG
WScript.Sleep 500
WshShell.SendKeys "{tab}{Enter}" '// switsch to "Save" and save
WScript.Sleep 1000

Set BASFL = nothing : set gApp = nothing

脚本来自网上，当时晚上随便看reader攻击面的时候随手找到的一个转换脚本，这个脚本的功能的调用Adobe Acrobat DC Pro的转换模块，把pdf转成图片。

其实脚本看起来没有任何问题，而且我使用的x.pdf也没有什么特殊支持，随便一个pdf文件都可以触发这个洞。问题不在于内存，在于逻辑。

触发漏洞
  1. 第一次运行vbs脚本启动转换，此时没有任何问题，这时候不要kill掉Acrobat.exe。
  2. 然后再次运行vbs脚本，因为Reader是单进程的，多的tab标签会以单独的线程体现，所以这个时候你不会看到第二次被打开的文件。
  3. 关闭已打开的pdf标签
  4. crash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
0:029> g
(874.74c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for Acrobat.dll -
Acrobat_6c400000!DllCanUnloadNow+0x591d3:
6c4d7318 8b4118 mov eax,dword ptr [ecx+18h] ds:002b:2b208bb0=?? ??????
0:000:x86> r
eax=2b208b98 ebx=00000001 ecx=2b208b98 edx=03c51138 esi=2b96edb0 edi=0000000 1
eip=6c4d7318 esp=0021f308 ebp=0021f308 iopl=0
c
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
2
Acrobat_6c400000!DllCanUnloadNow+0x591d3:
6c4d7318 8b4118 mov eax,dword ptr [ecx+18h] ds:002b:2b208bb0=??
??????
0:000:x86> dd ecx
2b208b98  ???????? ???????? ???????? ????????
2b208ba8  ???????? ???????? ???????? ????????
2b208bb8  ???????? ???????? ???????? ????????
2b208bc8  ???????? ???????? ???????? ????????
2b208bd8  ???????? ???????? ???????? ????????
2b208be8  ???????? ???????? ???????? ????????
2b208bf8  ???????? ???????? ???????? ????????
2b208c08  ???????? ???????? ???????? ????????

具体的漏洞分析的细节不再细述，逆向的工作量比较大，主要是管理PDDoc对象的问题。当时厂商也说这个问题好像有点复杂，他们需要做更多的测试工作，所以差不多从五月报告，到修复，我等了差不多四五个月的样子:(

0x02 : 类似的情况

很有意思的是，我在Adobe Reader系列、Foxit都发现过类似的情况，正常的文件，但是操作逻辑不正常，导致下层代码产生崩溃，比如一些数据不同步的情况(Foixt的一个洞)。

还有就是SourceTree的Windows版也有这样的问题，但是是个空指针，没人理吧估计。 就是在进行配置的时候，不按照他指示的逻辑向下进行，就会触发这个空指针。(依然没有修复，发了邮件也不理 T_T)

本月(2018.12)我又交了一个Adobe Acrobat DC Pro的越界读，也是这种类似的漏洞(鸡肋又没用)，完全正常的代码、文件，只是因为操作逻辑不对导致了程序崩溃。说实话我也不是很明白为什么会出现这么奇怪的bug，我每次都是在找攻击面、测试自己写的东西的时候发现的这些奇怪的bug。

0x03 : 引发的一点思考

在程序的复杂度剧增的现在，用了很多设计模式、框架糅合的程序的确很难保证没有类似的bug出现，比如Adobe这种支持很多功能、插件的PDF阅读器，在逆向的时候就发现了一层又一层的封装以及一些设计模式，搞得人一个头两个大。

上层的操作逻辑对下层代码的影响有时候真的很难考虑周全，或者说测试的时候也没往这个方向想，所以导致一些bug的出现，不过我估计除了安全研究员也没人去往这个方向搞 :( 我个人也没有什么开发相关的经验，就存在一个疑问:这部分问题怎么避免or及早发现?

最近也看到James的几个本地提权的洞，不由感叹逻辑洞是真牛逼，以后还是要多往这个方向想想。不过像Reader这种思路逻辑洞就只在穿sanbox的时候有见过？ 至今还记得zdi之前一波利用 __defGetter__和__defSetter__调用到特权api的那套骚操作…不过也被封的差不多了，基本gg :(

最后吐槽一下，洞好难挖…

0x04 : 其他人的工作

QuBo && heige 在kcon2018上的议题涉及到了一小部分这样的，只是他们做的更完善，在fuzz内存破坏漏洞、加入了操作逻辑的fuzz，就产生了一些很奇怪的case，比如点击xx下崩溃，以xx分辨率打开然后xxx崩溃…

很有意思的分享，虽然这类洞利用的可能性微乎其微（个人认为没有），但是很有趣，也是枯燥的漏洞挖掘生活中的一丝乐趣。

0x05 : 致谢信息

Zhenjie Jia of Qihoo 360 Vulcan Team (CVE-2018-12831)