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."
... then surely Adobe can do it. It's probably because Foxit is bigger and able to reassign resources better than Adobe ... oh wait ... how did Foxit beat Adobe on this fix?
I think you're all asking the same question I am. Is evince susceptible?
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?
It...won't work. Users are stupid. Not the programmers. The users.
Do you trust the source of this? "Sure, I trust Chuck not to forward me a virus" Of course, they never think that chuck is forwarding Anna K nekkid pics from Bob, who got it from Albert, who got it from Zed, who got it from Debby...
And of course, they'd never contemplate it might not actually be Chuck that sent it, but a virus Chuck opened up and scanned his inbox or address books. And that's just using issues that hit the streets over a decade ago.
No, nobody would *ever* innovate with malware, and actually do something like reply all to current emails to make them context sensitive in a current thread chain.
"Great point $SENDER, but there's a minor flaw. It's a bit hard to explain--but I've got it in this attachment... $CARBONCOPYLIST, can you confirm?"
Or run a multi-stage attack... or spoof an administrator saying to apply something... or host an e-card as shadyporn.cum, please click in the link and login with your AOL userid to continue...
No...users are the problem, and any amount of warnings you do will invariably result in one of two behaviors:
1) they will be told by IT to hit "ignore" once, and they will hit ignore FOREVER MORE.
2) they will be told it's dangerous by their nephew, and ignore it no matter what. If IT tells them to hit it "just once" they will either
a] lie and not actually hit it, but say they did
b] goto 1)
Bottom line--all people between keyboard and chair known as "users" are fucking incapable of exercising any judgement, discretion, or common sense.
Yeah, I'm in IT for a living. And my attitude isn't the problem. If you're incensed by this--you are.
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.
VB coders are going to be the first to the wall when the revolution comes!
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?
I don't think they care about Acrobat Reader anymore at all, too busy rolling in money from sales of Photoshop Crashing Edition 5, InDesign etc. Your solution is amazingly, a pop-up like ActiveX, UAC, and similar innovations which I think has been demonstrated does not work well on end-users. Confirm/deny reads like 'click here to be able to read the damn thing', the rest is blah blah blah do you trust your cat not to eat you at night. It's approximately as annoying as default deny, the sane approach. Bonus points if your accept/deny has an always accept option but not an always deny option.
You should set fire to your VBA bookshelf and buy HCI / UX books instead.
I'm almost done a "Database Design and Development" course at college. Turns out the course entirely relies on MS Access (not exactly what I had in mind when signing up). Anyway, in the later part of the course macros/VBA was embedded in the example files, and one of the first instructions in the book was always "Enable the contents" - but the book never bothered mentioning why the warning was there and what the purpose was. I'm sure at least half of my computer science major peers would click OK without thought.
"It doesn't disable JavaScript entirely," Xiong said. "It only partially disables JavaScript."
That line really bothers me. How many times before have ways been found around things like SQL sanitization procedures? Why not block ALL javascript unless it's explicitly enabled? I can't believe that they would let that go.
You've hit the nail on the head here. One of my users received a particularly well crafted email from "me" today asking her to download a patch for Adobe products. It even included what looked to be a forwarded conversation from our CEO. Had she not co .to domain. Typical users don't look for warning signs like that.
e to me asking a question about the instructions, she could very well have infected her machine. Nevermi d that the link was to a
If Murphy's Law can go wrong, it will.
Is it a coincidence that I read that Adobe is losing the grip on PDF just a few days after I read Job's "Thoughts on Flash", essentially dumping Flash from iPhones/iPads, and burning it at a stake? Or is Adobe's strategy really failing spectacularly before our own eyes?
I should've seen it coming -- I haven't used Acrobat Reader for years. PDF Xchange Viewer is my current favorite, though Foxit was my first off-Adobe alternative, back when.
Quem a paca cara compra, paca cara pagará.
Maybe PDF's support of linked source files cause some vulnerabilities
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.
PDF was supposed to be a document format. Since it turned into a programming platform and Internet platform to run executable files while reading a document, it "jumped the shark". THERE IS NO NEED TO USE JAVASCRIPT OR ANY OTHER EXECUTABLE PROGRAM WHEN READING A DOCUMENT. It's no wonder most agencies, departments, etc won't accept PDF for documents. It turned from something practical to something that only spammers and malware enthusiasts love.
PDF, for me, is as stupid and outdated as Steve Jobs, iTunes, Flash, Web2, Web3, MySpace, Facebook and patents.
Now, I make my living writing Visual Basic...
And you freely admit it here?... ;)
One that hath name thou can not otter
If FoxIt is gaining ground on Windows, they should consider releasing it for Linux. Abode actually beat them to that (more important, IMO) punch.
Plus, it will hopefully be the first decent PDF reader for Linux.
-Will P.
But that fails when everyone wants to start using this functionality, and a user has to constantly click allow. Regardless, how are end-users going to know what all this means? They just want to view the document. I think the failure is in even allowing executable code in a document. The point was a common format that could be viewed/printed from any machine. That's fine, let's stick with that. I really see no hope, because everyone wants every damn file format to be everything. Web pages, Flash apps, whatever, they want each one to have all the same features.
Ar
e you sure that some of your mac hines aren't alr
eady
in fect
ed?
Plain Text Format!
Even companies such as Adobe, Microsoft, and Apple with joint efforts could eventually make TXT format readers that have next-to-0 security holes. :)
Everybody on Windows uses .exe functionality... and this kind of thing is the basis for allowing or disallowing network connections from suspect applications. It's a last line of defense against newly discovered threats, and works well in combination with Anti-virus which can stop known threats, but has no way of knowing about today's new threat.
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.
Yeah, there should be some sort of "You can trust us, we're your textbook author and we included VBA macros in order to..." note somewhere in the book near the first introduction. Then again, if they were using VBA to prevent copying by students and not telling them about it, then that textbook should be burned.
And that's a save for the "Um, you're doing something odd here... are you sure?" system. That extra dialog box most likely prompted the question to you, which saved the day. Yeah, the IT admin might want the control to Just assume the user clicked "No!"... but I don't know the number of times where the IT guys have locked out the custom code I was paid by them to develop because it tripped a "changed .exe" flag. Yes, I'm the developer and you own the software... yes, I think we can trust that changed .exe file for this one time and for and for as long as I'm here. What, the guy who oversees both of us haven't told you they hired me? :)
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.
Pity this is so. If users were smarter, we wouldn't need smug nimrods like you in IT. Downsizing FTW! What amuses me is that you're actually complaining about the only thing that's keeping you employed.
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
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.
PDF/A is indeed the sane specification(though it has a few friends for slightly different purposes; but offering similar levels of standardness and sanity).
Trouble is, though, Adobe has very little incentive to stick to that(if some customer demands it, they obviously have an incentive to be able to emit sane PDF/A; but not much to stop there). Since the core, sane, bits of PDF are a royalty free standard, and Reader is free as in beer, Adobe only makes money if people buy the expensive versions of Acrobat, or heroically expensive "enterprise document workflow solutions" and so forth. Thus there are two pernicious forces at work: 1. If Adobe's de-facto PDF "standard" didn't keep sprouting tentacles of various sorts, it would be easier for competing products to reach parity, or "almost as good but a lot cheaper" status, and erode Adobe's profits. 2. Because Adobe's bread-and-butter involves worming their way into various horrible and convoluted enterprise document/form scenarios, their customers probably give them a lot of weird(and, outside of the customer's specific context, basically terrible) feature requests. "But if we could just embed Flash videos, we could consolidate the new-hire training module with the document compliance tracking system..." "Hey, could we work-in client-side input validation, and HTTP GET? It sure would save us a lot of time collecting the surveys that people fill out; but neglect to email back..", etc, etc.
Yeah, I'm in IT for a living. And my attitude isn't the problem. If you're incensed by this--you are.
Actually I was in IT for 14 years. I left IT last summer to go into the medical field. I didn't leave because of all the crappy hardware and software manufacturers. I didn't leave because of the stupid end users or inept management or outsourcing or any of the other crap that gets complained about. I left IT because so many of my coworkers were arrogant socially inept morons who were a pain in the ass to be around.
The VBA macros were probably being used to actually implement the example. I have seen far too many people (including academics) who think using Access to design a full database UI is a good idea.
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.
Because most people have no idea that there can be threats inside of PDFs and this kind of pop-up would only alert them that there could be a danger. Who wants that kind of publicity?
NO!
The solution is not to give choice of "run" / "don't run at all" where "run" means "run with full privileges - bloody hell, let's give administrator while we are at it!".
Why, after who know how many years of Java, cannot there be a sandbox?
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.
Come on dude, you should know better than this. Your average end user is going to click Yes to anything that pops up, especially when all they want to do is see the document they just opened.
The real solution is to not give documents the functionality of applications but I guess it's too late for that.
The last time I installed Acrobat Reader, it demanded a system restart.
It is a userland program. It reads user data files and displays them on the user's screen.
And yet it demanded an action reserved for system driver and kernel updates.
I propose this:
Every time a userland program demands a reboot, a programmer from the team responsible gets shot.
You don't keep your private info in a sandbox, and some programs need your private info in order to do what they're designed to do.
Or if you rename the file to a .pdfa or something like that, the reader will not enable "active" content.
You read about many exploits in Acrobat, but are they really exploits in the PDF format and/or JavaScript? What I'm really getting at is, does using an alternative PDF viewer (such as Foxit, Nitro, or MacOS X Preview) protect you from most exploits?
I've asked this question in a few places and tried to do some research on it, but I haven't found much relevant info at all.
As an IT admin, I'm not getting anyone to drop PDF as a format. That's insane. But this, along with the 9.2 update installing McAfee without permission, has made me decide my company will be moving to Foxit. Adobe has screwed me for the last time. For anyone's info, if you have Reader 9.0, without the McAfee install selected, and you then do a "Check for updates" update from within the program, McAfee AV will be installed. I now have to UNinstall it from a shit-ton of machines. Adobe is famous for bad installers, but this takes the cake.
You see, the issue is that Adobe's reader ALREADY HAS this protection. It always did! Try reading the "researcher's" (notice the quotes) so-called attack, use a version of Adobe Reader however old, and see how it works - guess what, you get a warning telling you that the PDF is trying to execute code and you should only allow it in case you trust it.
Read the report people, this is a non-issue where Adobe's name was only mentioned because it is fashionable to bash Adobe for whatever "security" issues (saying Foxit had a security issue - because it did! - would not have been news; but put Adobe too in the press release - now you have something that people will read! ).
a script or scanner I can point my directory of PDFs too? PDFs are a great attack vector when you have tons of IT folk downloading programming and sysadmin related ebooks ...
Belgian researcher, not Belgium researcher.
Please.
This product might have nice features but the uninstaller is a pain...
So if you want to try the free version of foxit, you better have to be ready to clean up manually once you uninstall it.
I would love to have documentation listing all the install options, and an easy way to make .mst files for automated silent distribution.
These options do exist, but they are scattered all over third-party forums that people discovered by trial & error.
This is why I use Postini and tell it to drop any email with mail from *@mydomain.com because unless you have an off-site mail server (for your Web site or whatever) sending out mail from *@mydomain.com, you should never see an email from your domain come into your network from the outside; it would never leave your internal mail server.
body massage!
Preview is a great program because it just works-- it opens pictures, has easily collapsible sidebars that handle menus, and its search gives context previews on the side. I have a lot of .pdf programming books, and it's just so much easier to read them on Preview. I dual-boot, and I hate the clunky Adobe Reader.
Then you get a specific pop-up telling exactly what is going to happen, "script requires read access to file personal.txt" or "to open a socket to blackhat.cn".
Not "do you want to run ... tough luck, you are now pwned".
It's this fucking iPhone keyboard. I know, I know. I should have previewed. I don't care what anybody says about the iPhone keyboard. My personal phone has a QWERTY keyboard with real buttons and I am much faster and more accurate on that thing. If only it could browse /. without shitting a brick.
If Murphy's Law can go wrong, it will.
Actually, we use Google mail for our mail services but with an on-site SMTP server for our multi-function scanners which don't support SSL. I do subscribe to Postini, and until we made the switch to Google Mail I did have a filter in place to drop anything from *@mydomain.com, but after switching to Google mail, the result was that any emails from the SMTP server on our LAN were dropped by Postini since they traverse outside of our Google mail domain. If our bloody multi-functions would support connecting via SSL to Google's mail servers I could reapply that rule, but as it is I'm stuck with what we've got.
If Murphy's Law can go wrong, it will.
Have a look at stunnel (stunnel.org): it's a generic SSL wrapper for TCP connections. Found this Google forum post where it's being used specifically for MFP and scan-to-email via Google's SMTP servers: http://www.google.com/support/forum/p/Google+Apps/thread?tid=1780781e814d05e6&hl=en
body massage!