poc: launch

Just recently I have been researching on PDF vulnerabilities again. I based my research on the work I did with David Kierznowski on PDF backdoors, that is publicly available here.

PDF is very interesting file format. It allows the PDF consumer to do almost everything they 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 something very dangerous to do. file:// protocol urls, launched in the browser, grant malicious JavaScript objects permissions to list the filesystem and steal confidential information. More information about the dangers of the file:// protocol can be found here and here.

That is not all, however. 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 relay on. Even if you do so, attackers are still able to launch local XSS on the victim machines.

I prepared several Proof of Concept files which you can try. This issue may not seam that big of deal, however, IMHO, it is quite big thing. Think about a situation where the victim receives an email with a PDF attachment. When they access the file, the exploit will execute and attack the file system. This can lead to sensitive information being exposed to external organizations.