Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security IT

Adobe Security Chief Defends JavaScript Support 216

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 sopssa ( 1498795 ) * <sopssa@email.com> on Tuesday January 05, 2010 @01:06PM (#30656834) Journal

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

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

  • Re:Simple solution (Score:2, Informative)

    by maxume ( 22995 ) on Tuesday January 05, 2010 @01:27PM (#30657244)

    Off is actually equivalent to block but ask. There are some (probably safe) scripted pdfs here if you want to clicky-clicky:

    http://www.planetpdf.com/developer/article.asp?ContentID=6828 [planetpdf.com]

  • by Anonymous Coward on Tuesday January 05, 2010 @01:32PM (#30657336)

    Missed the analogy, hmm?

    Chainsaw == Javascript
    Pram == Document

    Get it? He's saying that Javascript is the wrong tool for the job.

    Asshole.

  • Re:PDF forms? DIE! (Score:3, Informative)

    by Volante3192 ( 953645 ) on Tuesday January 05, 2010 @01:41PM (#30657506)

    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.

  • 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 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 Anonymous Coward on Tuesday January 05, 2010 @02:09PM (#30658028)

    "Well you can always use alternate PDF readers"

    ok - question.
    Is there an alternate reader (for windows and/or linux) that is
    1. F/OSS?
    2. supports filling out/saving forms and commenting?

    I've been reluctant to try Foxit, because they seem to be using their software to push the use of TrialPay (which smells like a scam). Maybe they're legitimate, but if they knowingly associate with a scam artist, it doesn't add to my confidence.

  • by pclminion ( 145572 ) on Tuesday January 05, 2010 @02:16PM (#30658116)

    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 of PDF was designed to map onto PostScript, but the reverse is not true. PDF readers have no PostScript processing abilities, and Adobe actively discourages the use of PostScript-specific features of PDF (which, sadly, still exist in limited form).

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

  • by LordLimecat ( 1103839 ) on Tuesday January 05, 2010 @04:02PM (#30659576)
    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.

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Working...