Forgot your password?
typodupeerror
Security IT

Adobe Security Chief Defends JavaScript Support 216

Posted by timothy
from the oh-it's-gotta-have-javascript dept.
Trailrunner7 writes "Despite the fact that the majority of [PDF-related] malware exploits use JavaScript to trigger an attack in Adobe's PDF Reader product, the company says it's impossible to completely remove JavaScript support without causing major compatibility problems. In a Q&A on Threatpost, Adobe security chief Brad Arkin says the removal of JavaScript support is a non-starter because it's an integral part of how users do form submissions. '"Anytime you're working with a PDF where you're entering information, JavaScript is used to do things like verify that the date you entered is the right format. If you're entering a phone number for a certain country it'll verify that you've got the right number of digits. When you click 'submit' on the form it'll go to the right place. All of this stuff has JavaScript behind the scenes making it work and it's difficult to remove without causing problems," Arkin explained.'"
This discussion has been archived. No new comments can be posted.

Adobe Security Chief Defends JavaScript Support

Comments Filter:
  • by richdun (672214) on Tuesday January 05, 2010 @01:04PM (#30656790)

    Why not let PDFs only display documents, and rely on web forms for submitting information? No? Too simple?

    I personally have hated PDF forms for some - as a Mac user, having an OS with great PDF support built-in, but still having to use Adobe's products to use their non-standard (or newly made standard) forms implementation is a headache.

    • Re: (Score:3, Informative)

      by sopssa (1498795) *

      Well you can always use alternate PDF readers, like Foxit Reader [foxitsoftware.com] (and no bloat either)

      • by pmontra (738736) on Tuesday January 05, 2010 @01:21PM (#30657124) Homepage
        Simply switching one user to another safer reader won't solve this security problem because most people use the Adobe's one. Disabling JavaScript by default in Adobe Reader would. People that for some reason have to use PDF forms will enable it or will be told how to by their IT department. By the way, I'm using evince on Linux to read PDF. I discovered now that it supports forms but apparently it doesn't have javascript. I'm probably safe.
      • by toleraen (831634) on Tuesday January 05, 2010 @02:01PM (#30657888)
        L [nist.gov] O [nist.gov] L [nist.gov]

        All NIST tracked vulnerabilities for Foxit in the last two years have been of the "open a bad PDF and get infected" variety. How is Foxit any better, other than executing infected PDFs faster?
        • by BitZtream (692029)

          Much like Linux exploits, the installed base is so small no one notices when the product gets exploited.

          Its no better, its just different exploits that happen to fewer total people. The percentage of installed users effected is likely identical, assuming the same ratio of exploits directed at Foxit versus Adobe Reader.

          You gain security through obscurity. No one cares about exploiting foxit really, the install base is too small compared to adobe reader, so the bad guys target the one that they get the most

        • Re: (Score:3, Informative)

          by LordLimecat (1103839)
          Lets see, the first one linked is for an addon, the second one is for version 2.3 which was old when that was released, and the third was for a non-current version. None appear to have been 0-day exploits (except MAYBE the last one), which Adobe Reader has had plenty of.

          So given that its faster, and has a better (though not perfect) track record, id say yes, it is better.
    • Re: (Score:3, Funny)

      by kestasjk (933987) *
      I'm also surprised the Adobe Security Chief didn't consider the option of ditching PDF for HTML in this interview
    • by fuzzyfuzzyfungus (1223518) on Tuesday January 05, 2010 @01:11PM (#30656960) Journal
      Your "solution" is only a solution if your business isn't peddling PDF software(not to mention the really expensive backendware that you have to buy from Adobe if you want to "enable your enterprise PDF form workflow" or whatever).

      There are well behaved, and standardized, subsets of PDF that are just fine. They know their place, they are a perfectly competent and pretty well supported way of slinging around documents that have to look a certain way. Outside of that, though, is the nightmare realm where Adobe just keeps cramming use cases into PDF, because PDF is what they own. Javascript, embedded Flash video, it's just a matter of time before they announce an alliance with VMware, to "Enable users to deploy entire Rich Enterprise Solution Stacks" just by emailing PDFs full of x86 virtual machines, complete with embedded video documentation, to one another...
    • Why not let PDFs only display documents, and rely on web forms for submitting information? No? Too simple?

      I propose we make a new read-only document format that's portable between machines. We could call it PRODF. We could also require that any format updates are backwards compatible with previous readers, so that the user doesn't have to update his &%(*% reader every month just to be able to read a document (hence the name "portable").

      • by reub2000 (705806)
        No. We need forwards compatibility to ensure that documents created today can be read by readers in the future.
    • Re: (Score:3, Insightful)

      by nametaken (610866) *

      Correct. This whole problem stems from this awful idea that PDF should be more than what made it popular. Its purpose is to make sure a document looks the same for everyone, regardless of a person's installed fonts or default margins, etc.

      In a struggle to monetize the PDF format and maintain relevance Adobe keeps adding all kinds of bullshit feature bloat that doesn't catch on, BECAUSE WE DON'T WANT IT. Take form submission. How many PDF forms have you seen in the wild? I haven't seen more than two in

      • by GIL_Dude (850471)
        I've seen lots of them. One per month at work for SOX compliance (unfortunately the crazy system our company bought uses them). One more just the other day from my kids school district for a form to apply to be in the school's "pathways" program (engineering program in this case). This form didn't even work right. The form field checking worked, but the submit button failed to do its email thing - so we had to print it and carry it in because you can't SAVE it. Another to apply to be a coach for the soccer
      • by FooAtWFU (699187)
        In the wild? Tax form PDFs. That's about it.
    • Why not let PDFs only display documents, and rely on web forms for submitting information? No? Too simple?

      Yeah, that was my thought as well.

      The reason I use a PDF is because I want somebody on the other end to see my document the way it is supposed to look. I don't want to worry about what font they have installed or which version of Word they're running or whatever. It's the digital equivalent of a printed page.

      I like that you can specify editable areas on a PDF... So that you can send somebody a form, that they can type on, and then print out or send back to you. That's nice.

      But that's about the extent of

    • by BitZtream (692029)

      Or, just do away with PDF in favor of a portable document format, like HTML which is supported on far more platforms than PDF, and far better than PDF in every conceivable way.

      As for PDF forms, has anyone ever seen them used properly. By that I mean made, actually will allow you to input data on them and allow it to be submitted to where it needs to go or printed or something useful?

      I've never seen a PDF form that worked.

    • Re: (Score:3, Interesting)

      by Rayonic (462789)

      PDF forms are used when the form needs to be printed in a very specific format, or at least needs to exactly emulate their paper counterparts. e.g., tax forms, standardized contracts, employee waivers, etc. Even with stylesheets set up properly, printing out HTML is always an adventure.

      So if an employee needs to, say, update their tax information, they can fill out the form online and submit it (securely) back to the employer. Then the employer can print it out themselves, file it, or whatever. Beats ma

    • Why not let PDFs only display documents, and rely on web forms for submitting information?

      You are faced with the problem of having to host a file which requires a server and an afternoon setting that all up. Then you have to provide a link to someone, which means they have to open it in a web browser. Which means you'll have to let that server through the firewall/dns, since you've got it all blacklisted to keep employees in line.

      Instead of being able to open it by whatever email client you want, as an attachment, that works across all platforms.

      I don't like them any more than the next guy, but

      • Yeah. That's the use case for it allright. Large enough company to not mind paying for all the adobe software required to send a one off pdf form.
  • Simple solution (Score:3, Interesting)

    by loganljb (1424009) on Tuesday January 05, 2010 @01:04PM (#30656794)
    Well, gee -- how about creating the equivalent of noscript for Adobe, then? That way, the user can decide for themselves if they want to run scripts in what they THOUGHT was just a formatted text document.
    • by Reason58 (775044)

      Well, gee -- how about creating the equivalent of noscript for Adobe, then? That way, the user can decide for themselves if they want to run scripts in what they THOUGHT was just a formatted text document.

      I don't have it installed on this machine, but I am pretty sure there is a setting to disable script support in all versions of Acrobat.

    • Re: (Score:3, Insightful)

      You can turn off javascript in Acrobat Reader.

      Every time you load a document with Javascript, you'll be warned that it may not display properly, and asked if you'd like to turn javascript back on.

      If you agree, the "on" setting sticks for subsequent documents, until you go into the menu and turn it off again.

      Can't you just taste adobe's eagerness to have you turn off javascript?
  • Seriously, how damaged would the world be without form-based PDFs? I removed almost every plug-in from my copy of Adobe Reader. I don't need their "rights management" or their "braille reader" or their "web submission plugin" or any of that other cruft.

    And somehow my life is not incomplete as a result.

    • by PIBM (588930)

      Just remove the pdf viewer altogether...

      The web is so much nicer without those ugly, slow loading, web browser crashing pdf junk...

      • by plover (150551) *

        Well, I am stuck because some stuff that I actually do want is provided only in PDF format. But the stuff I need is "information", not "function". I don't need yet another piece of software acting as a browser, or a mail client, or a media player, or a download accelerator, or a Swiss-army-knife.

        It's one thing to make a spec sheet available in PDF format. But don't expect me to order spare parts from it -- it's all I can do to make one browser trustworthy, let alone every other damn application on the bo

      • Re: (Score:3, Interesting)

        by Grishnakh (216268)

        What are you talking about? PDF is an excellent format for printed media; I look up data sheets online all the time, which are in PDF format.

        The problem is Adobe's crappy reader software. Don't use it; there's far better ones out there like Okular and Evince.

    • by Skuld-Chan (302449) on Tuesday January 05, 2010 @02:34PM (#30658368)

      (speaking as someone who has worked quite a great deal with implementing Acrobat forms...)

      End users don't need this stuff (it would be cool if IRS Tax forms were intelligent, but that would cut into the profits of a lot of tax prep companies). A lot of enterprises however use this stuff. I would agree its not the best solution in every case, but one thing it was used for frequently was a front end for some other system where they previously printed out, faxed in a paper form and then transcribed it by hand into some mainframe CRM app - well with Acrobat forms you can cut out a lot of that steps - keep the familiar forms, and keep training costs down to boot.

      Livecycle forms is just a development environment like anything else (SAP/Datatel etc) - and if you are used to it - great, if not - use something else.

      I do know - for end users being able to type into a form they previous wrote on was helpful because they knew where everything was and how the form worked. That certainly cut down training time, and calls to help desks.

      And no - no other pdf viewer (even foxit) is compliant enough to actually work within this workflow - its either Reader 8/9 or nothing.

      • Re: (Score:3, Interesting)

        by jonom (109588)
        I too develop interactive PDF forms using LiveCycle and I'd like to add a few things.

        Why PDF vs HTML forms? You don't have to be connected to the internet. Forms can be saved partially completed and be finished later (with Reader Extensions which allow saving, among other things, with Reader).

        Do you need a signature with that form? HTML fails. With PDF you can print the form out, sign it and send it in - with 2d barcode technology that form can be scanned in on the receiving end and all data retrieved ele

  • Tea and pramwiches (Score:5, Insightful)

    by daeley (126313) on Tuesday January 05, 2010 @01:07PM (#30656858) Homepage

    "Anytime you're working with a baby pram where you're, say, also carrying diapers, our chainsaw is used to do things like verify that the Pampers fit on that little shelf underneath. If you're carrying some groceries as well, the chainsaw verifies that you don't try to fit too much on there. When you push the pram, the chainsaw makes sure you push it to the right place. All of this stuff has the chainsaw behind the scenes making it work and it's difficult to remove without causing problems," Arkin explained.

  • The only thing I learned when we used PDF forms a few years ago was ... don't do it. Just no. Really, don't .
    • Re:PDF forms? DIE! (Score:4, Interesting)

      by Qzukk (229616) on Tuesday January 05, 2010 @01:17PM (#30657068) Journal

      The only thing I learned when we used PDF forms a few years ago was ... don't do it. Just no. Really, don't.

      PDF forms with javascript for web submission? I agree.

      In reality though, a lot of crap (especially government crap) still has to be done on paper, and until HTML+CSS gets to the point where I can reliably reproduce a form on paper, PDF is the best option, ahead of Word documents with 50,000 underscores that wordwrap when someone tries to write in them.

      That, or find someone with a typewriter.

      • by Mornedhel (961946)
        Or, y'know, a PDF could be generated by the server when the form is submitted, if a paper trail is really important.
        • Re: (Score:3, Informative)

          by Volante3192 (953645)

          He's referring to submitting a form by hand or by snail mail, not electronically.

          If you're going to the DMV, you're giving them a piece of paper. That is where PDF forms excel. You get the benefits of PDF (exact document reproduction) with the additional benefit of legible typed in data.

          • Or you have the user submit the data online and print out a barcode (1/2D) they can bring in and have scanned by someone at the DMV or where ever to lookup the record. Or the barcode is sent to their mobile device to be shown and scanned.
        • I maintained such a system for a while.

          People were supposed to fill in the HTML form, submit it, print the PDF from the next page, sign it, and mail it.

          The problem?

          Some people printed the HTML form, filled it in by hand, signed it, and mailed it.
          Some people filled in the HTML form, printed it, signed it, and mailed it.

          Not a lot – just enough to be irritating.

          (This despite a notice on the top of the HTML form telling you not to print it, and despite blank versions of the PDF form being available for pe

      • Word documents with 50,000 underscores that wordwrap when someone tries to write in them

        The correct way to create those is with an underlined tab character.

  • Simple answer (Score:4, Insightful)

    by just_another_sean (919159) on Tuesday January 05, 2010 @01:08PM (#30656874) Homepage Journal

    White listed docs/publishers are the only ones allowed to run JavaScript. White listing
    should be as easy as pushing a "Trust this document" or "Trust this publisher" button.

    Will it/can it be abused? Sure, but it's better then running script by default without
    user consent.

    • Re: (Score:3, Funny)

      by OzPeter (195038)

      And Joe Sixpack will say to him/herself

      "the only way I can see my embedded VMware virtual machine with full video documentation [1] is to click on the whitelist button for the producer. and I really want to see this .. so here goes".

      [1] Shamelessly stolen from a previous comment VMware embedded documents [slashdot.org]

  • Anytime you're working with a PDF where you're entering information, JavaScript is used to do things like verify that the date you entered is the right format

    I really can't remember the last time I saw a PDF that had a form in it that you could submit. Was it 2001? possibly 2003 at the very latest. The idea never caught on, and why would it? you get some minimal HTTP POST support in a proprietary format. To me it would seem more important that you have an up-to-date version of the form you are submitting, rather than having the form's formatting look *exactly* right without loss in formatting which is the whole point of PDF.

    JavaShit, forms, DRM in PDF files

    • I had to deal with a PDF form recently, from the DMV. Basically you filled it out and then printed it out.

      That's the only reason I could see for using a PDF form.
      (I'd rather type in than write in details...it'd take thrice as long to write legibly than it would to type it and print it.)

      • by plover (150551) *

        I had to deal with a PDF form recently, from the DMV. Basically you filled it out and then printed it out.

        Screw the DMV. If they're going to make me wait in line for an hour, they can spend an extra 10 minutes trying to figure out my hand writing.

        • by Skater (41976)

          I had to deal with a PDF form recently, from the DMV. Basically you filled it out and then printed it out.

          Screw the DMV. If they're going to make me wait in line for an hour, they can spend an extra 10 minutes trying to figure out my hand writing.

          You don't want to do that. I had a situation a couple years ago where the DMV misread what I'd written (and I have reasonably good handwriting) and put incorrect information for the lienholder on the title. Well, my credit union wanted me to fix it, of course, because they were afraid they wouldn't get paid if the vehicle was totaled. Long story short, it took three trips to the DMV (with hour-long waits each time) to fix the problem. I don't remember all the details, but I do remember one problem they

  • by Nomen Publicus (1150725) on Tuesday January 05, 2010 @01:09PM (#30656896)
    Why does a product called "Reader" have to process user input?
  • CS4 Scripting too (Score:5, Informative)

    by 0100010001010011 (652467) on Tuesday January 05, 2010 @01:11PM (#30656962)

    I didn't know this until recently, but you script most of Adobe's CS products (Photoshop, etc) with JavaScript.

    It's cross platform. The same scripts work on my Mac as they do on a Windows machine.

    I already know it, syntax isn't something foreign and there is a ton websites out there for JavaScript support.

    It makes stuff like making panoramas and HDR panoramas awesome.

  • Amazing that in the face of one known problem, someone knowledgeable about the issues can remain aware of another problem. This silly guy would be much better off to ignore all other issues when examining a problem, regardless of whether proposed solutions would have other undesired consequences.

    • Re: (Score:3, Insightful)

      by plover (150551) *

      It's obvious from this discussion that his *only* consideration is shareholder value.

      His job is to make sure that PDFs remain relevant. Adding plugins, or anything that makes people depend on PDFs, is their primary goal. Turning off features (such as disabling JavaScript) would reduce that primary goal.

      Security is valued only as long as it keeps people from complaining. He'll talk about security for hours, but in the end he has to justify whatever decisions the board told him to justify. He'd be much mo

  • His point is sound, but it dodges the real issue:

    1) Most of the time people aren't doing forms submissions. It's somewhat of an obsolete concept. We use HTML for that. We use PDF when we want to print something. (Which we do a lot less often than we used to)

    2) You can have Javascript that can do form validations without giving it commands like "open this file, write to it, then execute it" Adobe's Javascript security is stuck in 1998, back in the days of ActiveX controls that could trivially to break o

    • 2) You can have Javascript that can do form validations without giving it commands like "open this file, write to it, then execute it"

      You think you can have it without that... and then somebody designs a buffer overflow that usurps your security level and does exactly that.

    • If I had mod points, i would mod you up.

      Paper is really getting less important to People. PDF is best used for generating print ready documents or archiving old and newly created documents. It's a print media used read-only. When we need to submit data there are various better suited ways, today html/http is preferred (specially when cross-platform compatibility is of concern).

      Integrating form functionality and scriptability is a desperate try to transform a static print media into an interactive online med
  • by psbrogna (611644)
    I wish I was in a position where I didn't have to fix my strategic mistakes. It sure would be a nice a nice world if we didn't have to make mistakes and could call anything difficult a "non-starter."
  • Dont run it automatically. Have the default be JS off and a nice scary warning box about JS and how you should only enable it if you are certain this is a safe PDF. Sure, its not a perfect solution but its better than just having it on by default and running vulnerabilities at double-click.

    Not to mention, when I shut it off under Preferences - KEEP IT OFF. If its off in preferences, it helpfully reminds the user than its off and offers to re-enable it via the prompt. What the hell is Adobe thinking?

    While I

    • Re: (Score:3, Interesting)

      by Grishnakh (216268)

      Not to mention, when I shut it off under Preferences - KEEP IT OFF. If its off in preferences, it helpfully reminds the user than its off and offers to re-enable it via the prompt. What the hell is Adobe thinking?

      While I'm at it how about updates to the reader that arent 40-150 megabytes big or an updater that actually works. Right now, sane people should be considering Reader are very serious security vulnerability and migrating off the platform. Adobe has shown nothing but contempt for even basic security

  • Funny. The PDF format had forms before Javascript was tacked on. If they needed something to do validation they should have looked in house and used a language they already had like, oh I dunno... Postscript.

    • Re: (Score:3, Informative)

      by pclminion (145572)

      A PDF "form" is just a macro of content stream commands. It has nothing to do with a "Form" in the sense of a document with fields that are filled in. And if you're thinking of FDF, that's a different issue entirely. FDF represents form data which will be composed by software on top of a form -- what we're talking about here are user-filled forms, submitted from the reader. THAT functionality is almost entirely implemented in JavaScript.

      PostScript has nothing to do with PDF either. The content stream format

  • What's happened is Adobe has tried to retrofit Acrobat with tubes. They did it with much haste so as to get a foothold in the 'cloud' computing craze. What we now have is a hastily coded bloated application that's somewhere between IE5 and MS Word 95 in terms of security. Adobe needs to start over, they f#cked up and need to fix it.

  • ...that nobody uses these "I am an electronic form" features anyway. All we want is view and print documents. But then, PostScript did exactly that. Oh wait, PDF is based on PostScript. I never understood why it had to be Adobe and PDF that the world uses today. It could have been (a nice version of) Ghostview and PostScript. Hm, but then nobody could have sold PDF-Creation Add-Ons to MS Word, because you could have used a PS printer driver.

  • by gehrehmee (16338) on Tuesday January 05, 2010 @01:37PM (#30657434) Homepage

    We have Javascript in web browsers, and it's rare to see vulnerabilities this rare.

    What's the difference? Is Adobe just not sandboxing Javascript code properly? I've never really used Adobe's products for this... but what's to stop them from just using an established javascript implementation like that used in Firefox or Webkit?

    • by BitZtream (692029)

      Browsers are used FAR FAR more than PDF. Browsers user FAR FAR more likely to have already experienced these exploits and had them fixed.

      It isn't that Adobe isn't as good as it so much as that Adobe is just a new player in the JavaScript world.

      And for reference, Firefox and Adobe are sharing some implementation details.

      http://www.mozilla.org/projects/tamarin/ [mozilla.org]

      How the script interacts with the rest of the software is a problem. The exploits (without actually looking at these specific details) are generally

  • It smells like they painted themselves into a backward compatibility nightmare using a lightweight solution to what now needs to be a heavyweight security application because of its widespread usage. Anyone standing behind javascript as a security boundary on a compiled app is pretty much insane imho..
  • JavaScript is a feature that Adobe believes is useful enough to tolerate the security compromises.

    Or to rephrase it, Adobe Reader is so good, security doesn't matter as much as features.

    Yup. That's how they see it.

  • by leighklotz (192300) on Tuesday January 05, 2010 @02:04PM (#30657940) Homepage

    Adobe should move away from JavaScript and move to declarative form definition and validation, which carries no risk of code attacks from errant JavaScript. In fact, there is a standard for validating forms declaratively, called XForms. It lets you write validation expressions for saying when data is valid, required, readonly, or calculated from other data (i.e. totals), and also lets you assign data types using the widely-deployed XSD type names (integer, URL, string, regexp string, etc).

    XForms is modular enough that it's been incorporated into ODF, and there's no reason other that it can't be used in PDF to define and validate forms, other than that Adobe has a vested interest in maintaining its proprietary technology forms instead. There are a number of folks who would be quite ready to help Adobe incorporate XForms into PDF.

    There are in-browser JavaScript implementations of XForms (here [agencexml.com], here [google.com], and here [formfaces.com]), server side implementations a la GWT (here [orbeon.com] and here [sourceforge.net]), and mobile implementations (here [picoforms.com]).

    I've been working with XForms for many years, and find it an excellent solution for deploying rich internet applications; we've switched implementations a few times, and have had to do only minor changes to our applications, so using a standard preserves our investment in stuff already written.

  • by RevWaldo (1186281) on Tuesday January 05, 2010 @02:38PM (#30658410)
    I actually used Javascript in Adobe Acrobat a few years back. As part of a workflow process we were regularly bundling sets of PDFs together into one large PDF. This included a title page and a table of contents (talking about a printable one, not bookmarks.) So I futzed around with the Javascript and came up with a way to have the person creating the one big PDF to:

    - open a blank Title/TOC PDF
    - click a checkbox to unhide the form elements.
    - enter a title into a field, which appeared on both the title page and the page headers
    - check off which documents were being included in the PDF, which then showed those lines in the TOC. The chapter numbering e.g. 1), 2), 3) etc. also changed to match.
    - click the checkbox again to hide the form elements, leaving just the printable title and TOC portions.
    - save as a new copy, then bundle it with the other documents.

    Pretty slick IMHO. It saved the users from having to waste time opening Word to create a new Title/TOC page every time.
    But that being said, what happened in the PDF stayed in the PDF. It didn't have to connect to the web, etc.
    This is of course the classic reason for bloatware. The feature that's unbelievably-useful-couldn't-do-my-work-without-it for 2% of the users is completely worthless to the other 98%, and we all belong to at least one group of 2%.
    Adobe also has the problem of full Adobe Acrobat Pro vs. Acrobat Reader. Any changes made to a PDF in Acrobat Pro have to be compatible within Acrobat Reader e.g. if I highlight text in Pro and save the PDF I expect everyone who opens the PDF later on to see it too. Otherwise they could simply make all the additional features (including Javascript support) plug-ins and be done with it.
  • Yeah, right (Score:3, Insightful)

    by Locke2005 (849178) on Tuesday January 05, 2010 @02:56PM (#30658720)
    All of this stuff has JavaScript behind the scenes making it work and it's difficult to remove without causing problems," Arkin explained. Translation: "We designed the products with a flawed security model to begin with and fixing that now would cause applications built on them that depend on defects in the security model in order to operate to no longer work."

Genius is ten percent inspiration and fifty percent capital gains.

Working...