PDF Strikes Back
Recently I have been researching PDF again. I based my research on the work I did with David Kierznowski on PDF backdoors, which you can read more about here here.
PDF is very interesting file format. It allows the user to do almost everything he/she can think of and this is the reason why I find it quite insecure. When David posted the findings on how to backdoor PDF files, he also mentioned that it is possible to automatically launch http:// urls inside the default browser. The Adobe folks did not took that warning seriously and as such a partial fix was released for Reader 8.0: the user is asked for confirmation when a desktop document tries to launch an external link at load time.
Where does this leave us? I found that the checks implemented in Reader and Acrobat Trial are inefficient. My investigation shows that it is possible to launch file:// urls, which is sometimes a dangerous to do, depending on the situation. The file:// protocol urls, launched in the browser, grant malicious JavaScript objects permissions to list the filesystem and steal confidential information for example. More information on this can be found here and here.
So far, so good. Now, if you are familiar with the Adobe UXSS PDF Vulnerability, you probably know that RSnake has found that attackers can launch dangerous exploits via a locally stored, default PDF file. Cleaver administrators, solved this issue by removing the file from the file system. This is not really a fix but a quick patch which you should not rely on 100%.
As usual, I prepared several POCs you can pick and play with.

