Slashdot Mirror
Hacker Finds Multiple PDF Backdoors
Gungadin writes "Eweek.com has a story about a British security researcher figuring out a way to manipulate legitimate features in Adobe PDF files to open backdoors for computer attacks. David Kierznowski, a penetration testing expert specializing in Web application testing, has released proof-of-concept code and two sample PDF files to demonstrate how the Adobe Reader program can be rigged to launch Web-based attacks without any user action. He claims there are least seven different ways to backdoor a PDF."
Basically, the PDF standard allows for a lot of ways to access data on your local machine, in databases, and through your web browser. It also has mechanisms for running JavaScript, and even executing arbitrary local programs. Some of these things require a user to click on a link in a PDF, and some require just openning the PDF or visiting a specific page in the PDF.
Many of these features are quite helpful for corporate clients, but maybe shouldn't be allowed by default.
In retrospect, some of the other free 3rd part PDF viewers, that don't support those fancy features, might be better for people to use:
http://www.icesoft.com/products/icepdf.html
Really, it's using pdf supported code to undertake malicious actions. The code may or may not work in other readers depending on wether the specific feature has been implemented, however it is at least known for sure that Adobe Reader has the advanced support in place for the exploitable features.
If this signature is witty enough, maybe somebody will like me.
Use FoxitReader (http://www.foxitsoftware.com), much lighter and faster than Adobe Reader, and probably with its own set of vulnerabilities, but unlikely to be much targeted.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
I think he's defining a vulnerability to be a piece of poorly written code, like an input buffer that's vulnerable to an overflow. Or a URL parser that's vulnerable to a carefully formatted string. The code in that case is not behaving as intended.
An exploit would be more along the lines of the old outlook viruses. Outlook used to allow arbitrary scripts to be run on mail loading, and messages to be sent to an entire address book. Combine these two, and you have an exploit. It's behaving completely as intended, but they never expected someone to use the features like that.
The PDF reader is behaving as intended, though nobody expected the intended behavior to add up to that.
The ______ Agenda
The vulnerabilities aren't in the format per se, but more in Adobe's implementation of their Acrobat products.
Apple, along with Preview, has its own implementation of rendering and viewing PDFs
Error 407 - No creative sig found
The Mac version of Acrobat reader is actually not affected by these vulnerabilities; they only occur on the Windows platform.
Create a parallel directory to installdir/adobe/acrobat 7.0/acrobat/plug-ins/ directory, call it plug-not, and move all non essential plug-ins into that directory.
I just want a reader, not a full fledged pseudo-browser app with tons of security exploits - there's already one called Internet Explorer on my PC!
So I've moved away: Accessibility, Acroform, ADBC, EScript, Multimedia, weblink, webpdf, etc.
Now when you open those "exploit" links, you get an pop-up saying, "The plug-in required by this 'URI' action is not available."
You get another benefit from this. Your acrobat reader will load sooo much faster too!
In the article the second "back door demo (PDF)" link just points to the same PDF as the first link. The correct link is:
http://michaeldaw.org/projects/backdoored2.pdf
Better yet, use Ghostscript. It's also much lighter and faster than Acrobat Reader, and -- more importantly, and unlike Foxit Reader -- is Free Software.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I've tried both exploits on Linux (acroread & Gnome Document Viewer). Neither work. The first asks if I want to connect to the web site and I have to explicitly click "Allow" (in acroread). The second of-course doesn't work because I don't have any ODBC junk on my Linux box. But that doesn't mean that it can't talk to other unsecured ports on my computer. That would be interesting to find out.
FYI, the pdf rendering engine is named after the futurama popplers: http://en.wikipedia.org/wiki/Poppler_(software)
Load PDFs with Acrobat in seconds
Not necessarily.
Some gPDF vulnerabilities.
I didn't find any Evince vulnerabilities in my limited search, but that doesn't mean there will not be one. You will most likely remain safe from 'sploits targeted towards Adobe users by not using the Adobe PDF reader, but that should be obvious.
There are two types of people in the world: those who divide people into two types and those who don't.
The first "vulnerability" is the ability to have clickable web links in a pdf. It's a standard feature of the PDF document language, and all conforming viewers should support it. I'd be surprised if evince doesn't, but most of the other free viewers are too primitive.
In my view this claim is idiotic anyway. I just found a giant security hole in HTML where if they view my page or email with a link and if they click on it, it might take them to a malicious site.
*yawn*
Opening the first PDF with Preview does not cause Safari to launch, and appears to show a static Google web page. No outbound traffic was observed when opening the PDF in Preview. Opening the PDF using Acrobat 5.0, 6.0 , and 7.0 appears to cause Safari to launch and open "http://www.google.com/owned.html". It looks like Preview is not vulnerable to this particular attack, while at least some Adobe Acrobat readers for OSX are vulnerable.
PDF stores the result of running a PostScript program; it's not actually a Turing complete programming language itself. It'd be like trying to claim that a JPEG image is Turing complete because you generated it in Python. Any file format like JPEG can be thought of as a language of a sort because it contains "commands" (bit codes) to "generate" the image, but it's certainly not Turing complete.
While there's a close link between PostScript and PDF that make the translation from PostScript to PDF easy to do, the fact that PDF merely stores the output of a PostScript interpreter (rendering commands) is why it's faster and simpler to implement than full PostScript.