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.
This is Slashdot. Right so far. We are mostly alternative OS users, i.e., Linux, *BSD, OSX, etc(sorry OS2 users). Right again. These articles are annoying in that they are so very broad. Its like the typical American-slashdotter who assumes the "Government" refers to the U.S. only in any context. This article presumes the user base is that of Windows users. Why not specify this is a ****OS NAME HERE***** issue? The article says this is a Windows XP SP3 issue. Great, that's nice to know, but I shouldn't be presented with an article that makes me think I need to go and update/remove Adobe from my Debian machine. Pure FUD. FUD' beyond belief! /rant
Bored at work? Play Game!
It comes up faster because it's always running.
The right to protest the State is more sacred than the State.
I'm using a non-Adobe PDF reader: Foxit Reader. It's commercial and not open source, but the non-Pro version is free to use; it's functionally far superior to the open source ones that were mentioned at Slashdot recently. I really hope the OSS projects can reach the level of sophistication of Foxit, because it's really my baseline of minimum PDF-reader functionality. The first OSS reader that can duplicate Foxit's sophistication will get a new convert.
Great, I've got to wait 2-3 weeks for this to be patched.
Oh wait, Adobe have a 4 MONTH OLD bug that means we can't even run Acrobat 9 within our company:
http://www.adobe.com/go/kb404597
*seethes*
What's worse is that Autodesk hit this exact same bug with their beta of Design Review, and fixed it within a couple of weeks, so I know there's a fix for this.
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.
Does hardware Data Execution Prevention stop it from happening, in that this exploit would crash Reader instead of cause an exploit if DEP is enabled? I wish companies would suggest that as a possible mitigation, even if not all computers support it.
I did dumpbin /headers and saw that the EXE header for AcroRd32.exe has the "NX compatible" bit set. This means that DEP will be automatically enabled for Reader on Vista.
However, that doesn't cover XP. XP 32 SP3 has an API call named SetProcessDEPPolicy to request enabling DEP for your process. Adobe should modify Reader to call this function if it exists. (It exists on Vista SP1 as well, but Vista SP1 will already enable it due to /NXCOMPAT.)
XP 32 SP2 and XP 64 SP2, even though they have DEP, don't have a way to enable it if the system-wide DEP setting is "opt in" - the default. And there's no way to opt in that these support. (Google Chrome has code to use an undocumented system call to enable it, but it actually has no effect.)
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Sumatra PDF Reader is Open Source, less than half the size of Foxit (1/15th the size of Acrobat) and has search, text-read, copy-paste, and plenty of keyboard shortcuts. It's very quick and streamlined and makes Foxit look bloated in comparison.
Right now it's windows only, unfortunately.
http://blog.kowalczyk.info/software/sumatrapdf/index.html
Where in the article does it say this is a WindowsXP SP3 issue? The Adobe official site clearly states "Platform: All platforms". The shadowserver site says they tested it works with WindowsXP SP3, not that it's restricted to this.
Phillip.
Property for sale in Nice, France
- 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.
Google Chrome leverages this Vista feature. http://dev.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ The sandboxing feature in Vista is implemented with process integrity levels. A process with "low integrity" is severely restricted in what it can do on the system. Adobe could use this feature for Acrobat. They actually do use it (they have to) for Flash, as the Flash plugin in IE runs inside the sandbox. The crux is that a sandbox is often so severely restricted that you need a helper (called "broker") process to do the privileged stuff such as downloading/uploading files etc. Flash actually made their own broker process for Flash and left a stupid bug in there. That was the flaw which allowed Vista to be compromised in last years' pwn2own contest.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
On the other hand, the actual advisory from Adobe states that the issue affects all platforms. You'd think they'd be the ones to know best, right?
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.
Comment removed based on user account deletion
It's all quite possible under Linux. Realistically, a number of protection mechanisms (many of which started being routinely used in Vista) should prevent buffer overflow attacks. Certainly they should prevent arbitrary code from making OS-level hacks -- which is probably why it only works on XP. While Linux also can use these mechanisms, the only sandboxing it does by default is user/administrator separation (like Vista does, and like XP doesn't generally do). To get OS-level access, you'd need a privilege-escalation attack, which are reasonably hard to come by for both Vista and Linux (and can be very hard to make reliable under Linux). Alternately, the attacker could just steal your data from the one running Acrobat Reader process he gets, which Linux won't do anything about.
Proper application sandboxing is certainly possible, but not easy. (Your PDF viewer, for example, should have read-only access to its own code, read-only access to a single PDF file, write-only access to screen space for drawing, and read-write access to scratch memory space. That's it.)
In fact, Adobe Reader is really not the issue -- the issue is that the OS doesn't impose MAC (mandatory access controls). MACs should control exactly which resources an application can use, and this can be as restrictive as desired.
Of course, it is difficult to come up with the necessary rules, and to "retrain" the user base, which is why (for example) SELinux MAC was phased in gradually on Fedora.
It took Fedora quite a few releases to fully implement MAC - Fedora Core 2 introduced SELinux (with strict policy as default), Fedora Core 5 was the first version to use modular policies, but was not running in strict mode, Fedora Core 6 introduced the Policy Editor, Fedora 7 a GUI admin tool, Fedora 8 a GUI Policy Creation tool and user lock-down (and, some Adobe plugins would no longer run), and Fedora 9 and 10 offer fine-tuning.
"When SELinux was initially introduced in Fedora Core, it enforced the NSA strict policy. For testing purposes, this effectively exposed hundreds of problems in the strict policy. In addition, it demonstrated that applying a single strict policy to the many environments of Fedora users was not feasible. To manage a single strict policy for anything other than default installation would require local expertise.
At this point, the SELinux developers reviewed their choices, and decided to try a different strategy. They decided to create a targeted policy that locks down specific daemons, especially those vulnerable to attack or which could devastate a system if broken or compromised. The rest of the system runs exactly as it would under standard Linux DAC security."
So, it took version 2 through 8 (or 9, arguably) for Fedora to introduce MAC to a largely technical community. This was done over 4 years.
It will take much longer than 4 years to get equivalent security provisions in Windows, given the user base. Given the convenience of "plug-in" architectures, it is very difficult to tell if a program is actually misbehaving! MAC is really the only way that I am aware that behavior can be monitored. For example, code can be introduced as a plug-in (or, via exploit), but that code isn't dangerous until it tries doing something bad. The definition of "bad" is what is in question -- it could mean sending email, or sending LOTS of email, or modifying files it didn't create. If none of THAT is happening, it may simply have been an automatic installation of some "fun cursors" desired by the user.
Just another "Cubible(sic) Joe" 2 17 3061
Here's a plug (from a satisfied user) for the open source but Mac-only Skim.
Skim is lightweight, fast, and scriptable. It allows for easy markup of PDFs either to the original file or separately. With Skim, one can convert annotations between its open format (written into the extended attributes) and Adobe's PDF standard. Combined with Apple's Preview.app, Skim can provides much of the functionality Adobe Acrobat.
blog
FoxIt does have a Firefox plugin. I don't use it myself as I prefer to read PDFs in a external application and not bloat my Firefox install.
No Opera, Safari, or Chrome plugin however.
No, I don't have anything planned for you, I promise...