Tuesday, November 30, 2010

cve-2010-4091 exploited ? – 0.2 – Adobe Reader 9.3.0

Starting from the malwaretracker sample (see my previous posts) seem that edx and ecx are set to some interesting values:


Thursday, November 25, 2010

cve-2010-4091 exploited ? – 0.1

Trying to reversing the shell code contained within the PDF that seem exploit CVE-2010-4091, in according with the sample reported by MalwareTracker, it’s been founded the following URL:


From Robtex:


The URL above at this time is down or not more available. Did really exploited for retrieve malware from womens-puzzle.com ? :) .  Many Thanks to binjo for his support and tools.  For the PDF check my previous post: http://extraexploit.blogspot.com/2010/11/cve-2010-4091-exploited.html 

All this things continues to be weird and funny! (WOMENS-PUZZLE.COM :-) ).  IMPORTANT: The PDF reported is not sure that exploit, really, the CVE-2010-4091

Friday, November 19, 2010

cve-2010-4091 exploited ?

November 24,  2010 – Update:

Looking for other  exploiting attempts I found a Malwaretracker sample where the PDF seem spread via URL that contains:  filepdf.php@v=zday


The following analysis report the objects used within this PDF (that is different from the fulldisclosure PDF):


November 22 , 2010 – update:

Some interesting (and useful) notes about the original full disclosure PDF PoC published on full disclosure mailing list:

Who’s looking for eggs in your PDF?

November 19, 2010:

This is my latest result. Seem that with a crafted PDF as explained by Haifei Li in his paper (see previous posts for reference), the code flow looks like could be hijacked. At least I have this impression from the debugger response as you can see in this screen shot:


feedback and suggestion are welcome. Some notes: this is only an attempt to try to understand better this issue.  My mistakes in this stage are very likely.

Thursday, November 11, 2010

cve-2010-4091 – printSeps - exploitation attempts

November 26, 2010 – update:
This is a very useful  presentation (from Immunity Sec) where is possible get some methods for approach the reversing of  Java script engine in Adobe Reader context:

Attacking Embedded Languages

November 16, 2010 – update:
In previous post I didn’t report where is the place in the AcroRD32.dll where the memory corruption is triggered (as result of the use after free bug).  The following screen shot is the leak screen shot:


At first view, the AcroRd32.dll offset 0094450, seem a zone involved with Acro Heap Manager, so this could confirm some of my doubts for the question like “where to play whit this bug ?”. So, IMHO, this bug is due from the double handling mechanism of the heap. In other words what the OS heap management has previously freed may be that the Adobe Heap Manager try to free again with the result as show.  I hope to release a more detailed analysis as soon as possible.

November 11, 2010
In my previous post (http://extraexploit.blogspot.com/2010/11/full-disclosure-xplpdf-adober-reader-94.html)  it’s been followed  the timeline and what is called exposure time for this bug that seem have a bit strange history. After my initial analysis,  only few details has been released about. But after play a bit with this flaw I can confirm once of the latest and most clear comments fromVUPEN via Twitter:

exploiting the PDF printSeps was complicated. It involves allocating/freeing chained blocks before triggering the flaw

After this tweet I started to looking for more informations about. So IMHO a good support for “allocating/freeing before trigger” the flaw may be get from” heaplib” as well documented in


Is possible fitting the heaplib.js for Adobe Reader and insert inside a crafted PDF for obtaining the heap handling ? For this goal code be usefull play with what is called Acro Managing Pool. A very interesting reference is from a Fortinet researcher:


The heaplib.js for Internet Explorer is here:

Anyway what I could say from my experience with this flaw is that the PDF posted on full disclosure seem leaks of something and using a debugger may lead you on the wrong way sometimes. Are only ideas which could be wrong as well right. Feedback are welcome.

Thursday, November 4, 2010

full disclosure xpl.pdf Adober Reader 9.4 poc - printSeps() - cve-2010-4091

November 26,2010 – Update:

Thank you, Mario, but our printSeps() is in another castle !

November 22, 2010 – Update:

Who’s looking for eggs in your PDF?  (reported also in  cve-2010-4091 exploited ?)

November 16, 2010 – Update:

Security updates available for Adobe Reader and Acrobat – ABSP10-28

November 9, 2010 – Update:

Adobe  PSIRT released - CVE-2010-4091

US-CERT response:

November 8, 2010 – Update 2:

VUPEN confirms the "remote code execution"

November 8, 2010 – Update 1:

Some screenshots of my brief analysis for this bug.  The vtable where is referenced the PrintSeps() method:

the location where the Javascript code is being processed:
Where Adobe Reader 9.4 crash after PrintSeps is processed:

November 5, 2010 – Update:

emerging threats Snort sign


eEye report as remote code execution


Adobe response:


November 4, 2010:
The vulnerable method seem: printSeps():

more info:

The original xpl.pdf is retrived via




Wednesday, November 3, 2010

CVE-2010-3962 - yet another Internet Explorer RCE

Update - November, 12 2010:
Amnesty International Hong Kong Website Injected With Latest Internet Explorer 0-day

Update - November, 5 2010:
CVE-2010-3962 - BindShell proof of concept:

Metasploit Module

More on the IE 0-day - Hupigon Joins The Party

Update - November, 4 2010:
the memory corruption proof of concept is (place the following code as is within a HTML file):

(From: http://twitter.com/yuange1975/status/29593742541)

Microsoft Internet Explorer CSS "clip" Attribute Memory Corruption

November, 3 2010:
New IE 0-Day used in Targeted Attacks

The issue seem related to a "use after free" bug when are parsed some CSS tags sequence.
Once of the implicated malware seem a Backdoor.Pirpi variant.

Other links:

Microsoft Security Advisory 2458511 (workaround included)