1619, 1/81 ȸ¿ø°¡ÀÔ  ·Î±×ÀΠ 
   err0r2
   http://javaphile.org
   ÇãÁ¢ÇÑ °¨È¸ - VI

http://www.hackerschool.org/HS_Boards/zboard.php?id=Free_Lectures&no=1199 [º¹»ç]


¿À´ÃÀº ±×³É ´Ì~¿ì~½º Çϳª¸¸ ±×³É ÆÛ¿À±â·Î Çß´Ù.

Ãâó:

  http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219


When PDFs Attack - Acrobat [Reader] 0-Day On the Loose

The Shadowserver Foundation has recently become aware of a very severe vulnerability in Adobe Acrobat affecting versions 8.x and 9 that is currently on the loose in the wild and being actively exploited. We are aware of several different variations of this attack, however, we were provided with a sample last week in which we were permitted to analyze and detail in this post. We want to make it clear that we did not discover this vulnerability and are only posting this information to make sure others are aware and can adequately protect themselves. All of our testing was done on Adobe Acrobat Reader 8.1.0, 8.1.1, 8.1.2, 8.1.3 (latest release of 8), and 9.0.0 (latest release of 9). We have not confirmed via testing that the exploit actually works on Adobe Acrobat (non-Reader) but believe that it will also affect it as well.

Right now we believe these files are only being used in a smaller set of targeted attacks. However, these types of attacks are frequently the most damaging and it is only a matter of time before this exploit ends up in every exploit pack on the Internet. As a result we are also not going to provide any specific details on how the exploit works despite the fact that information is known. We know several of the details on the internals thanks to a good friend of mine -- Matt Richard. He took a look at the file for us last week and provided the following:

The malicious PDF's in the wild exploit a vulnerability in a non-JavaScript function call. However, they do use some JavaScript to implement a heap spray for successful code execution. The malicious PDF's in the wild contain JavaScript that is used to fill the heap with shellcode. Since this exploit relies on both JavaScript and non-JavaScript components there are some potential reliability issues which has led to confusion over which platforms are affected.

Testing of the exploit with XP SP3 using Adobe Reader 8.1.1, 8.1.2, 8.1.3 and 9.0.0 shows that the vulnerability results in code execution on all of them. There may be cases where Adobe Reader crashes without code execution, especially on systems with more physical memory and faster processors. This is likely due to the race condition needed to populate the heap before certain data structures are parsed by Reader.

The exploit can be effectively mitigated by disabling JavaScript. In this scenario Adobe will still crash but the required heap spray will not occur and code execution is not possible. There may be a method for populating the heap with the necessary shellcode without JavaScript, however if such a technique exists I am not aware of it. As a general rule I like the idea of both disabling JavaScript in Adobe Reader and also flagging PDF documents containing JavaScript at perimeter devices.

In Matt and I's testing, we found that disabling JavaScript would definitely prevent the malware from being installed on the system. However, it would still result in the crash of the application. We would HIGHLY recommend that you DISABLE JAVASCRIPT in your Adobe Acrobat [Reader] products. You have the choice of small loss in functionality and a crash versus your systems being compromised and all your data being stolen. It should be an easy choice.

Disabling JavaScript is easy. This is how it can be done in Acrobat Reader:

Click: Edit -> Preferences -> JavaScript and uncheck Enable Acrobat JavaScript

We believe Adobe is aware of this issue and actively working to address it. However, we felt it was necessary to release this information to let people know how to mitigate against the attacks as they can be devastating. Right now multiple Antivirus companies detect this threat. We will update this post as we have more information that we can share on this.

A special thanks to the kind source that provided the file to us last week for analysis.

---

It has been pointed out to us that Symantec may have been protecting against this since February 12, 2009. We have not had it confirmed but believe they detect it as Trojan.Pidief.E which has a write-up here.
We have also been informed Trend Micro currently detects this threat as "TROJ_PIDIEF.IN".

=>Posted February 19, 2009, at 03:03 PM by Steven Adair

¹¹ ±×Àú ±×·¸´Ù´Â°Í...½Ã¸¸ÅÃèØ :Bloodhound.PDF.6

http://www.symantec.com/en/th/enterprise/security_response/writeup.jsp?docid=2009-021215-2608-99

ÇÊ¿äÇÏ½Ã¸é ¿¬¶ôÇϽñæ...

  Hit : 17098     Date : 2009/02/20 02:16



    
     [°øÁö] °­Á¸¦ ¿Ã¸®½Ç ¶§´Â ¸»¸Ó¸®¸¦ ´Þ¾ÆÁÖ¼¼¿ä^¤Ñ^ [29] ¸Û¸Û 02/27 22422
1618   realip_finder(asm ver)     ÇØÅ·ÀßÇϰí½Í´Ù
02/05 1191
1617   realip_finder     ÇØÅ·ÀßÇϰí½Í´Ù
02/05 1136
1616   ¸®´ª½º Ä¿³Î&¿î¿µÃ¼Á¦ °³·Ð (1)     ÇØÅ·ÀßÇϰí½Í´Ù
11/02 1538
1615   stack overflow »çÀÌÆ® ¹ø¿ª     ÇØÅ·ÀßÇϰí½Í´Ù
07/09 1881
1614   [L.O.B ¿øÁ¤´ë] - troll     ÇØÅ·ÀßÇϰí½Í´Ù
07/08 2306
1613   [L.O.B ¿øÁ¤´ë] - orge     ÇØÅ·ÀßÇϰí½Í´Ù
07/07 2233
1612   [L.O.B ¿øÁ¤´ë] - darkelf     ÇØÅ·ÀßÇϰí½Í´Ù
07/07 2184
1611   [L.O.B ¿øÁ¤´ë] - wolfman     ÇØÅ·ÀßÇϰí½Í´Ù
07/03 2149
1610   [L.O.B ¿øÁ¤´ë] - orc     ÇØÅ·ÀßÇϰí½Í´Ù
07/03 1911
1609   [L.O.B ¿øÁ¤´ë] - goblin     ÇØÅ·ÀßÇϰí½Í´Ù
07/02 2196
1608   [L.O.B ¿øÁ¤´ë] - cobolt     ÇØÅ·ÀßÇϰí½Í´Ù
07/02 2462
1607   [L.O.B ¿øÁ¤´ë] - gremlin     ÇØÅ·ÀßÇϰí½Í´Ù
07/02 2071
1606   [L.O.B ¿øÁ¤´ë] - gate     ÇØÅ·ÀßÇϰí½Í´Ù
07/02 1963
1605   ARP ½ºÇªÇÎ - Part.1 -     ÇØÅ·ÀßÇϰí½Í´Ù
04/20 2424
1604   http ½º´ÏÆÛ ±¸Çö     ÇØÅ·ÀßÇϰí½Í´Ù
04/20 2087
1603   pcapÀ¸·Î ÆÐŶ ½º´ÏÆÛ ±¸ÇöÇϱ⠠   ÇØÅ·ÀßÇϰí½Í´Ù
04/20 1958
1602   ÇØÄ¿½ºÄ𠸸ȭÀÇ ÀÚµ¿À¸·Î ½ºÄµÇÏ´Â ÇÁ·Î±×·¥     ÇØÅ·ÀßÇϰí½Í´Ù
02/18 2284
1601   ½Ã½ºÅÛ ÄÝ ÃßÀû È®ÀåÆÇ[2]     ÇØÅ·ÀßÇϰí½Í´Ù
01/19 2508
1600   °£´ÜÇÑ ½Ã½ºÅÛ ÄÝ ÃßÀû ÇÁ·Î±×·¥ ¸¸µé±â     ÇØÅ·ÀßÇϰí½Í´Ù
01/18 2495
1 [2][3][4][5][6][7][8][9][10]..[81]

Copyright 1999-2026 Zeroboard / skin by Hackerschool.org / Secure Patch by Hackerschool.org