Foxit Reader 2.2 two potentially exploitable bugs

Hi all,=0D
=0D
I would like to post here some =0D
problems that i found in Foxit =0D
Reader 2.2 software. =0D
=0D
I sent to the company support =0D
two depthly detailed descriptions =0D
about these bugs with both pdfs =0D
causing them. The answer =0D
from the company was:=0D
=0D
"Hello.=0D
 =0D
Both Foxit Reader and Adobe Reader cannot open the files you send us.=0D
These files have been damaged.=0D
Thanks much."=0D
=0D
I downloaded the foxit reader 2.2 =0D
software today to test the pdf =0D
files again. The crashses continue =0D
there. The company seems to be not =0D
very interested on these reports. =0D
I hope these descriptions that =0D
i will post here was interesting =0D
for anyone.=0D
=0D
Analysis 1:=0D
-----------=0D
http://www.vallejo.cc/proyectos/foxitreader1.htm=0D
=0D
Autor:  Javier Vicente Vallejo=0D
Web: www.vallejo.cc=0D
=0D
Abstract=0D
=0D
Foxit Reader 2.2 is prone to a =0D
vulnerability when a malformed =0D
pdf is parsed. =0D
=0D
Affcted versions=0D
=0D
Tested with Foxit Reader 2.2, =0D
Windows XP Media Center Sp2. =0D
=0D
Analysis=0D
=0D
The vulnerability occurs when =0D
a malformed /ExtGState resource =0D
is parsed. In this case the ExtGState =0D
resource was supplanted with a /Font =0D
resource, but the type of the resource =0D
continued being ExtGState:=0D
=0D
261 0 obj=0D
<</Type /Page /Parent 126 0 R /MediaBox [0 0 259 408 ]/CropBox [0 0 531 6=
66 ]/Resources <</ProcSet [/PDF /Text] /ExtGState <</R7 7 0 R>>>> /Conten=
ts [20 0 R]>>=0D
endobj=0D
=0D
7 0 obj=0D
<</FirstChaaa 1=0D
/Type /Funt /FontDescriptor  23 0 R=0D
/BaseFont /xxxxxxxxxxxxxxxxoman,Italic=0D
/Subtype /TrueType=0D
/Encoding /WinAnsiEncoding=0D
/LaitChar 211=0D
/Wodths [    ]=0D
>> =0D
endobj=0D
=0D
23 0 obj=0D
<</zzz9=F0E /oooooo>>=0D
endobj =0D
=0D
Under these conditions it seems Foxit =0D
allocates differents structures waiting =0D
to complete that memory with the content =0D
of the /ExtGState resource. However =0D
when it finds fields associated with =0D
a /Font resource, it tries to parse =0D
them anyway, and it completes the memory =0D
for that structures with incorrect =0D
data. This situation occurs because some =0D
functions (mainly the one located at =0D
address 0x4d1ed0) are common functions =0D
to parse any type of field for any type =0D
of resource. So, when some fields of =0D
a /Font dictionary are found under =0D
a /ExtGState resource, the fields are =0D
read and interpreted, and the allocated =0D
structures are filled with incorrect data.=0D
=0D
This facts cause different errors in =0D
the execution. For example, this code:=0D
 =0D
004A6E04   C74424 04 000000>MOV DWORD PTR SS:[ESP+4],0=0D
004A6E0C   0F84 9A000000    JE foxit_re.004A6EAC=0D
004A6E12   8B41 08          MOV EAX,DWORD PTR DS:[ECX+8]=0D
004A6E15   48               DEC EAX=0D
004A6E16   83F8 08          CMP EAX,8=0D
004A6E19   0F87 8D000000    JA foxit_re.004A6EAC=0D
004A6E1F   FF2485 BC6E4A00  JMP DWORD PTR DS:[EAX*4+4A6EBC]=0D
=0D
The instruction mov eax,[ecx+8].  =0D
Ecx+8 should contain a valid pointer, =0D
but the content of that memory is the=0D
 value of the first name of the =0D
 dictionary of the object 23 0 obj. =0D
 We can control this value so we =0D
 can control [ecx+8], for example.=0D
=0D
Modifying this dictionary name =0D
with different values we find =0D
crashes and invalid access at =0D
different EIP. For example with =0D
names with length under 8, it =0D
uses the last bytes of the name =0D
as a pointer at EIP =3D 0x4A6EE7. =0D
With larger names it completes=0D
the structure in a different =0D
way and the behaviour is =0D
different.=0D
=0D
23 0 obj=0D
<</zzzzzzz /oooooo>>=0D
endobj =0D
=0D
004A6EE7   8B41 08          MOV EAX,DWORD PTR DS:[ECX+8]=0D
004A6EEA   83E8 02          SUB EAX,2=0D
004A6EED   74 23            JE SHORT foxit_re.004A6F12=0D
004A6EEF   83E8 07          SUB EAX,7=0D
004A6EF2   75 14            JNZ SHORT foxit_re.004A6F08=0D
004A6EF4   8B41 14          MOV EAX,DWORD PTR DS:[ECX+14]=0D
004A6EF7   8B49 10          MOV ECX,DWORD PTR DS:[ECX+10]=0D
004A6EFA   50               PUSH EAX=0D
004A6EFB   E8 20200000      CALL foxit_re.004A8F20=0D
=0D
The code involved in this =0D
vulnerability is complex, lot of =0D
FPU and mathematical operations, =0D
etc... It is difficult to find=0D
correct values to exploit the =0D
vulnerability, however i think =0D
it is possible to exploit it by =0D
choosing some appropiated values =0D
for the input dictionaries and =0D
using heap spraying to facilitate =0D
the shellcode execution (heap =0D
spraying could be possible using =0D
javascript embedded into the own =0D
pdf file. The supplied pdf file =0D
uses javascript with some /Annots =0D
events so we can do heap spraying =0D
before the crash occured).=0D
=0D
Analysis 2:=0D
-----------=0D
http://www.vallejo.cc/proyectos/foxitreader2.htm=0D
=0D
Autor:  Javier Vicente Vallejo=0D
Web: www.vallejo.cc=0D
=0D
Abstract=0D
=0D
Foxit Reader 2.2 is prone to a =0D
vulnerability when a malformed =0D
pdf is parsed. =0D
=0D
Affcted versions=0D
=0D
Tested with Foxit Reader 2.2, =0D
Windows XP Media Center Sp2. =0D
=0D
Analysis=0D
=0D
The vulnerability occurs when a =0D
page with a malformed /XObject =0D
resource is rotated (it works =0D
if we add the /Rotate field =0D
to the page too).=0D
=0D
4 0 obj=0D
<< /Type /Page=0D
/Parent 3 0 R=0D
/Rotate 170=0D
/Contents [ 25 0 R ]=0D
/Resources <<=0D
/ProcSet [ /PDF /Text /ImageB /ImageC ]=0D
/XObject <</Im23 23 0 R>>/Font << /TT3 33 0 R  >>>>=0D
>> =0D
endobj=0D
=0D
23 0 obj=0D
<</Length 11643/Filter/DCTDecode/Width -28986631481/Height 5/BitsPerCompo=
nent 8/ColorSpace/DeviceRGB/Type/#6eject/Name/?#4825#6#25n#00=B0#6e#6en#2=
5n#72=C2&#402;=C9#25n&#8482;#r3/Subtype/Image>>=0D
stream=0D
........................=0D
endstream=0D
endobj=0D
=0D
 =0D
By modifying the values of width =0D
and height fields, Foxit performs =0D
invalid write memory access to =0D
different memory addresses:=0D
=0D
For example, =0D
At EIP=3D51b896, width=3D-28986631481, height=3D5:=0D
=0D
0051B88F   8B4C24 20        MOV ECX,DWORD PTR SS:[ESP+20]=0D
0051B893   83C4 04          ADD ESP,4=0D
0051B896   89443E 08        MOV DWORD PTR DS:[ESI+EDI+8],EAX (eax=3D0x0,e=
si=3D0x10c7fd8,edi=3D0x26f0020)=0D
0051B89A   8B4424 10        MOV EAX,DWORD PTR SS:[ESP+10]=0D
0051B89E   43               INC EBX=0D
0051B89F   83C1 04          ADD ECX,4=0D
=0D
At EIP=3D0x51b799, witdth=3D-87146603762, height=3D5:=0D
=0D
0051B799   8937             MOV DWORD PTR DS:[EDI],ESI=0D
0051B79B   7E 08            JLE SHORT FOXITR~1.0051B7A5=0D
0051B79D   8977 04          MOV DWORD PTR DS:[EDI+4],ESI=0D
0051B7A0   E9 1C010000      JMP FOXITR~1.0051B8C1=0D
0051B7A5   DB4424 14        FILD DWORD PTR SS:[ESP+14]=0D
=0D
...=0D
witdth=3D-87146603762 EIP=3D51b799 write->4994e93c eax=3D0 ecx=3Dc1a4027f=
 edx=3Df5a60633 ebx=3D12efd0 esp=3D12ef18 ebp=3D12ef74 esi=3D0 edi=3D4994=
e93c=0D
witdth=3D-69826555658 EIP=3D51b799 write->a82df00 eax=3D0 ecx=3Dc181027f =
edx=3Dfdc5c868 ebx=3D12efd0 esp=3D12ef18 ebp=3D12ef74 esi=3D0 edi=3Da82df=
00=0D
witdth=3D-56992150114 EIP=3D51b799 write->16a509d8 eax=3D0 ecx=3Dc194027f=
 edx=3Dfac27dcc ebx=3D13efd0 esp=3D13ef18 ebp=3D13ef74 esi=3D0 edi=3D16a5=
09d8=0D
witdth=3D-65571130766 EIP=3D51b799 write->1419ad20 eax=3D0 ecx=3Dc192027f=
 edx=3Dfb62d4f6 ebx=3D13efd0 esp=3D13ef18 ebp=3D13ef74 esi=3D0 edi=3D1419=
ad20=0D
witdth=3D-28986631481 EIP=3D51b896 write->37b8000 eax=3D0 ecx=3D10c7fd8 e=
dx=3D0 ebx=3D431ff6 esp=3D13ef18 ebp=3D13ef74 esi=3D10c7fd8 edi=3D26f0020=
=0D
witdth=3D-87146603762 EIP=3D51b799 write->497cd994 eax=3D0 ecx=3Dc1a4027f=
 edx=3Df5ac0a15 ebx=3D13efd0 esp=3D13ef18 ebp=3D13ef74 esi=3D0 edi=3D497c=
d994=0D
...=0D
=0D
=0D
With paimei framework and a py =0D
script for randomizing the witdth, =0D
i have got multiple invalid read =0D
and write operations to completely =0D
different memory addresses.=0D
=0D
I have not exploited the vulnerability =0D
yet, but it seems possible to exploit it.