See you in the Adobe playground…
June 16, 2010
Let’s see how to run an external Adobe Reader process from a pdf file that’s being displayed in a web browser.
This *technique* is a derivate of the pdf-into-pdf embedding post. It also uses the GotoE action to jump away to an embed pdf. I just discovered that doing this from a browser viewed pdf it runs a different process of the Adobe Reader. The ability of running a new, fresh and separated process has some interesting exploitability implications.
In older Reader version (previous to 9.2.3?) doing this also served as a way to bypass DEP optIn, but by now we have to settle with just this two facts:
[+] Whatever happens in the separate Reader will not crash the browser, potentially enabling other chances to exploit it.
[+] It makes it possible to develop exploits for highly predictable memory layouts.
We already posted here a step by step howto programatically embed a pdf file into another one, and also how to jump into the embed one. In that case the goal was prove there was a way to hide the nature of a malicious pdf into a better looking one.
Basically the GotoE pdf action documentation describes a way to open or jump to a pdf in another window. That’s accomplished crafting the NewWindow flag accordingly(setting it to true!). Check out how a new window opening GotoE action will look like..
/S /GoToE /T <</N (embedfile.pdf) /R /C /NewWindow false >> /NewWindow false >>
We’ve embed this minimal pdf file into a pdf shell that will jump to it, escapeTheBrowserMini. When you try that from a standalone reader it will open different window or tab depending on the Reader version, but in any case share the same process due to the magic of some IPC, but when run from a simple click in a web browser it will, for some reason, be forced to open the target pdf in a different Adobe Reader process. (tested in IE8/Opera/Chrome/FF+ADBE9.3.2)
That was great!
But Hey! This crash my browser!!
If you jump to a crashing pdf yes. And as we were filtring with the possibility of preventing the whole web browser to crash along with Abobe in the case of a bad pdf, we need to keep going a little more…
Surprisingly Abobe does some parsing on the father instance every time it jumps to an embedded pdf, so the browser will crash if we jump away to a crashing pdf. But this situation will not go so deep. If you jump to a pdf that jumps again to a third one the web browser grandfather will not be affected.
We control whether to jump to a pdf in a different window or if it replaces the current one with the embed pdf. Using that we can arrange a couple of nested GotoE and pdfs so a single separate window is opened. A behavior like that may be emulated making it jump from the web browser to a pdf shell in a separate NewWindow where it jumps again, this time replacing the current PDF in the same window. A minitool to do this is pasted here and also here.
Test it hard and check out this 100 windows pdf! WRAAAAH!