Slashdot Mirror
Foxit One-Ups Adobe In Blocking PDF Attack Tactics
CWmike writes "Foxit Software, the developer of a rival PDF viewer to Adobe's vulnerability-plagued Reader, released an update on Tuesday that blocks some attacks with a 'safe mode' that's switched on by default. Foxit Reader 3.3 for Windows' 'Trust Manager' blocks all external commands that may be tucked into a PDF document. 'The Foxit Reader 3.3 enables users to allow or deny unauthorized actions and data transmission, including URL connection, attachment PDF actions, and JavaScript functions,' the update's accompanying text explains. Last week, several security companies warned of a major malware campaign that tried to dupe users into opening rigged PDFs that exploited an unpatched design flaw in the PDF format, one attackers could use to infect users of Adobe's and Foxit's software. That flaw in the PDF specification's '/Launch' function was disclosed in late March by Belgium security researcher Didier Stevens, who demonstrated how he could abuse the feature to run malware embedded in a PDF document. He also reported he had figured out how to change Adobe Reader's warning to enhance the scam."
They used to say there was no way an image file or text doc could spread a computer virus... then buffer overruns were discovered in image handlers, and Microsoft added VBA macros that basically had the full power of Visual Basic at its disposal to Office, and away it went!
Now, I make my living writing Visual Basic, so there's no way I want to see VBA going away. Still there needs to be some safety to prevent a VBA macro from using unknowing users' computers from flooding the Internet with useless traffic... and the solution is pretty simple: If an Office doc contains VBA code, a warning is shown to the user asking them if they trust the source of the file, and would like the code to be enabled. If the user declined, macros won't run but users can see the static content in the file.
So.. that's the solution being employed here. They're effectively saying "Hey, this PDF is using network functionality, do you trust it to do that?" That should shut off the threat vector while still allowing the functionality to be used in trustworthy situations... why isn't this something in Adobe's official reader yet?
The only problem with all that is that most users just shrug and say, um, sure -> OK.
IMHO, for corporate use anyway, Foxit should add some way to leave the default "don't let
it run" enabled and prevent users from turning it off. Just to give us poor, overworked
sysadmins a way to prevent non-root/non-Administrator user "Just click OK" (TM) syndrome.
I believe MS does provide a way to handle the VBA situation you described but it's been
a while so not 100% sure
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
Is this really a "feature" that should be celebrated? This should have been implemented since the beginning. If you're making a PDF reader, and the PDF spec has an "execute" functionality, shouldn't everyone developing these programs have seen the spec and realized what this could do?
The problem is that the PDF specification was created at a point in time when you had a reasonable expectation that software would not do bad things to your computer intentionally.
A method to invoke an external program was put there for flexibility I am sure and it did offer a reasonable way to extend the functionality of the PDF document structure. The same thing is in WinHelp, for exactly the same reason. It allows a "tutortial" document that by clicking on active parts would invoke external programs to do things.
Now we have a situation where virtually nothing can be trusted to do what it is claiming to do. If you get an email with a file with any sort of active content in it you can assume that it will do something bad.
Where 15 years ago "active content" was something to be desired and provided extensability, today "active content" is a way to compromise computers and steal from people. A significant problem for Adobe (and plenty of others) is how to eliminate the possibility of bad things happening with active content while retaining the functionality? Today, I would say active content has to go, period. Anyone that is using and relying this needs to change their methods.
It is a pity that we have to give up flexibility and extensability because of criminals that we cannot or will not police.
There simply should not be active content in a PDF. PDF means "portable document format", not "program-distribution file". I believe the sane specification is called PDF/A (A for "archive"): No external references, no active content (no scripting, no video, no audio, no actions), no encryption, no blocking print or copy. PDF readers should have a simple preferences toggle: [x] restrict to PDF/A subset.
One idea is with Acrobat itself. If there is a need to run code or fill a PDF form, the PDF should be signed. Verisign isn't perfect, but in general, if their cert says that a PDF came from a company, it did, and if there is an exploit, fingers can definitely be pointed in that direction.
At the minimum, unsigned PDFs should not be allowed to run scripts. If the user wants to run scripts, he or she will need to explicitly turn the functionality on.
Voila. Problem taken care of. Companies can have their interactive forms, and the mischief makers are locked out. Of course, there is the issue about a mischief-maker getting a Verisign cert, but that is more of the fault of the CA.
And there are a lot of companies, big and small, that are learning about pdf printing via open source tools, making Acrobat a waste of money. If Acrobat isn't being used to create the documents, why use Acrobat Reader?
Still there needs to be some safety to prevent a VBA macro from using unknowing users' computers from flooding the Internet with useless traffic
Yes, it's called a sandbox. Let the VBA code run in a very limited environment, specifically don't let it access the filesystem or the internet. What's so hard about that?
and the solution is pretty simple: If an Office doc contains VBA code, a warning is shown to the user asking them if they trust the source of the file
You've never actually watched people other than computer experts use a computer, have you? If you had you'd realize they ignore those long, boring, cryptic messages unknowing programmers such as yourself put up in front of them. They don't care, and they just want to get their work done. By relying on this approach that "the user will know what to do in this situation!" (when in fact they have no idea and are just confused) you've trained people to simply click through these messages in hopes that the program will work anyway (which sometimes it does).
So.. that's the solution being employed here. They're effectively saying "Hey, this PDF is using network functionality, do you trust it to do that?"
What the hell happened to the approach of my document just being a damn document, and not having to try to have all these whizz-bang features of accessing the internet? The fill in forms are neat and useful, but that doesn't require anything but a sandbox. Putting a scripting language in a format people commonly exchange is just stupid, and will only lead to more security problems. The shit adobe has pulled off has lead me to stop trusting reader entirely, and just use alternative PDF readers in hopes they're not programmed by idiots who just want to add more gold plating and whizz-bang features to an application that was essentially "done" about 10 years ago.
AccountKiller
But since the average amount of registry entries is around 100,000 and the average amount of files is around what, 50,000? (Not even counting different versions and different configuration file entries), wouldn’t that mean
230 * 100,000 * 50,000 = 150 trillion "different platforms" or 25 * 150 trillion = 3,75 quadrillion different configurations? ;)
Or is it just, that when you make not really different setups count (like languages, which are not part of the code to test in such multilingual apps, or not actually different versions of Windows or Linux), that you can come up with whatever insane number you want? ;)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
There is absolutely no excuse for using PDF unless you need the Flashy extra features like forms. As a device-independent printable format, PostScript and DVI are superior as well as devoid of code execution or networking features.
We've almost taught people not to send Office documents in emails - next step, eradicate PDFs.
But LF,CRLF, or in the case of pre-OSX mac, CR?
Blocking PDF exploits is a great first step, but is there a way to detect infected PDF files, and disinfect them? I have no problem leaving Foxit permanently in safe mode, but it would be nice to be able to trust a PDF file once in a while, and be able to turn the JavaScript/etc back on for files I trust.