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.
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.