Slashdot Mirror
Adobe Flaw Heightens Risk of Malicious PDFs
snydeq writes "Security companies warn of a new flaw in version 9 of Adobe Reader and Acrobat that could compromise PCs merely by the opening of a malicious PDF. Although attacks are not yet widespread, hackers are exploiting the flaw in the wild, gaining control of computers via buffer overflow conditions triggered by the opening of specially crafted PDFs." Adobe is calling the flaw "critical" and says a patch for Reader 9 and Acrobat 9 will be released by March 11.
The problem is a buffer overflow + using javascript to fill the overflow with shell code (which is OS/CPU specific). I just did a test on x86 linux and acrobat reader for linux is affected as well.
- If you want a format ISO standardized.
- If you need long term archiving, being sure that after several years your document will be the same even if your computer and your printer have changed.
- If you don't need fancy new stuff, video, sounds.
- But you still want wide support PDF has for reading and printing everywhere.
Then use PDF/A.
This is a subset of PDF. It can be produced by Acrobat, but also a wide range of other vendors applications and scanners, including OpenOffice.
You're proposing to attack the problem in the least efficient possible way. This is yet another in a long series of exploits in AR that use the fact that in its default configuration it executes JavaScript embedded in PDFs. The right way to approach this, as a matter of design, would be not to embed a Turing-complete language in a file format that doesn't need it. Once you embed a Turing-complete language in the format, you're giving the bad guy the ability to run any code he wants on the user's machine. The moral of Turing's theorem is that it's essentially impossible to have any automated check that determines what a piece of code will actually do when you execute it. So yeah, you can try to sandbox it, but that's a last resort.
You're comparing with a web browser. A web browser is qualitatively different. In a web browser, the user (a) wants to be able to run javascript code, and (b) expects that such a thing will happen. In a PDF reader, there is typically no reason for the reader to want it to run JS, and the reader has no sane reason to expect it to run JS. Actually, the reason Adobe made AR execute JS by default was that it wanted to be able to do things that are inherently inimical to the user's interest. JS allows the creator of the PDF to determine who's reading the document, and also provides a mechanism for DRM. Lots of people who create PDFs want to believe in the DRM fable that they can give a document to other people, but then control the use of the document after that. As with all DRM, it's inherently impossible to make it work right as long as the user has hardware that they're really allowed to use as a general-purpose PC. E.g., to remove the DRM from a PDF on a linux box, you can do this: gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=b.pdf a.pdf -c '.setpdfwrite'
As a user, there are basically two sane things you can do. (1) Don't install AR on your machine. Use something else, such as evince on linux, or foxit on windows. They're faster anyway. (2) If there really is extra functionality in AR that you need, turn off JS. To disable js, go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript".
Find free books.
the "nice" feature on this is that you can copy and paste protected documents.