PDF Strikes Back
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.
comments
Tried poc01 on Adobe Acrobat Reader 8.0 (Windows XP SP2) and it does open ‘C:’ using the default web browser.
It’s interesting that Adobe Acrobat Reader 4.0 does open ‘C:’ using Windows’ ‘explorer.exe’ as opposed to the default web browser.
FYI. Nothing happens using Foxit reader on win XP2. So opening documents this way should be considered a little more secure.
Scary!
Because it reveals my user name which is very important in order to guess some of the vulnerable htmls that might be present in my temp directory. These HTMLs can be the exploited further may be using http://www.gnucitizen.org/proj...../poc01.pdf.
c:\docume~1\USERNAME\locals~1\temp\poc02-2.pdf
Is this a new issue or is this the same issue that you reported in http://www.gnucitizen.org/blog.....er-danger?
Only with some new Poc’s ?
Wokker, it is a new issue. However, I do use the Universal PDF XSS to better explain the risk. Wait for my blog entry which will detail this finding.
It is also work in my Acrobat 6.0 (but only tow tests). Pdp, not all PoCs worked in my case, just first two.
poc01.pdf - work (open file:///C:/)
poc02.pdf - work (show the file path)
Other three: poc03-ie.pdf, poc03-ff.pdf and poc03-op.pdf didn’t work. Because my system (Win XP SP2) didn’t like file names with # character. So that PoCs didn’t work in my Mozilla, Firefox and IE.
This is weird! Thanks.
I’m sorry, but can you tell the difference between UXSS and XSS ? I mean, when do I have to call it XSS and when UXSS ?
Thanks !