Starting from the malwaretracker sample (see my previous posts) seem that edx and ecx are set to some interesting values:
Tuesday, November 30, 2010
Thursday, November 25, 2010
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:
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
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
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
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
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:
November 5, 2010 – Update:
emerging threats Snort sign
eEye report as remote code execution
November 4, 2010:
The vulnerable method seem: printSeps():
The original xpl.pdf is retrived via
Wednesday, November 3, 2010
Amnesty International Hong Kong Website Injected With Latest Internet Explorer 0-day
Update - November, 5 2010:
CVE-2010-3962 - BindShell proof of concept:
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):
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.
Microsoft Security Advisory 2458511 (workaround included)