Adobe Security Chief Defends JavaScript Support

← Back to Stories (view on slashdot.org)

Adobe Security Chief Defends JavaScript Support

Posted by timothy on Tuesday January 5, 2010 @05:00AM 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.'"

40 of 216 comments (clear)

Min score:

Reason:

Sort:

Easy but far too simple solution by richdun · 2010-01-05 05:04 · Score: 5, Insightful

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.
1. Re:Easy but far too simple solution by sopssa · 2010-01-05 05:06 · Score: 2, Informative
  
  Well you can always use alternate PDF readers, like Foxit Reader (and no bloat either)
2. Re:Easy but far too simple solution by kestasjk · 2010-01-05 05:08 · Score: 2, Funny
  
  I'm also surprised the Adobe Security Chief didn't consider the option of ditching PDF for HTML in this interview
  
  --
  // MD_Update(&m,buf,j);
3. Re:Easy but far too simple solution by fuzzyfuzzyfungus · 2010-01-05 05:11 · Score: 5, Insightful
  
  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...
4. Re:Easy but far too simple solution by pmontra · 2010-01-05 05:21 · Score: 3, Interesting
  
  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.
5. Re:Easy but far too simple solution by nametaken · 2010-01-05 05:32 · Score: 2, Insightful
  
  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 the last ten years. Adobe isn't about to give this up though. They've committed to these BS features, they're not going away now regardless of how irrelevant or dangerous they are.
  Look into a good alternative reader. Adobe is not a customer-centric company. It never has been.
6. Re:Easy but far too simple solution by clone53421 · 2010-01-05 05:44 · Score: 3, Funny
  
  Dreamweaver?
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
7. Re:Easy but far too simple solution by ristonj · 2010-01-05 05:45 · Score: 2, Funny
  
  Shhhh....you'll give them ideas!
8. Re:Easy but far too simple solution by toleraen · 2010-01-05 06:01 · Score: 4, Informative
  
  L O L
  
  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?
9. Re:Easy but far too simple solution by nitroscen · 2010-01-05 06:05 · Score: 2, Insightful
  
  You should really read the posts you are replying to before bashing them. The guy was just saying it won't solve the problem. He didn't say it 'has had no impact'. He was simply stating that the solution to this problem requires some action on Adobe's part... just like how the solution to most security problems you bring up require some action on Microsoft's part.
10. Re:Easy but far too simple solution by Rayonic · 2010-01-05 06:27 · Score: 2, Interesting
  
  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 mailing around paper or having someone come into the main office.
  
  --
  [PowerPoint] is a tool for capitalist presentation
11. Re:Easy but far too simple solution by LordLimecat · 2010-01-05 08:02 · Score: 2, Informative
  
  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.
12. Re:Easy but far too simple solution by morgan_greywolf · 2010-01-05 08:18 · Score: 2, Interesting
  
  As a smart company, don't you think there's a REASON that Adobe continues product development on Acrobat? Or do you think they're just throwing away their money without any profit expectation?
  Of course they have profit expectation. But Acrobat is more of a sideline business for Adobe and it always has been. Acrobat will likely continue being a standard bearer, to be sure, but I have personally witnessed at least 5 different enterprises in the past few years cut their number of Acrobat licenses. IT management has realized that Acrobat simply isn't necessary for every employee that must generate PDFs and that there are plenty of alternative tools with either a zero cost or very cheap licensing -- there's at least one shareware tool I can think of in use at Ford Motor Co. and Xerox has a tool included with their DocuCenter workgroup/enterprise-class multifunction devices (printer/fax/scan/email) for generating PDFs as well. Tools like this are deemed "good enough" for most purposes.
  Why don't you try working in an actual corporate IT environment before you go spouting off.
  
  --
  My blog
13. Re:Easy but far too simple solution by mad.frog · 2010-01-05 08:40 · Score: 3, Funny
  
  ...and that's how Emacs stayed its original, trim self.
Simple solution by loganljb · 2010-01-05 05:04 · Score: 3, Interesting

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.
1. Re:Simple solution by fuzzyfuzzyfungus · 2010-01-05 05:13 · Score: 2, 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?
2. Re:Simple solution by maxume · 2010-01-05 05:27 · Score: 2, Informative
  
  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
  
  --
  Nerd rage is the funniest rage.
Tea and pramwiches by daeley · 2010-01-05 05:07 · Score: 5, Insightful

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

--
I watched C-beams glitter in the dark near the Tannhauser gate.
Simple answer by just_another_sean · 2010-01-05 05:08 · Score: 3, Insightful

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.

--
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
1. Re:Simple answer by OzPeter · 2010-01-05 06:53 · Score: 2, Funny
  
  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
  
  --
  I am Slashdot. Are you Slashdot as well?
No, not a good idea at all by Nomen+Publicus · 2010-01-05 05:09 · Score: 2, Insightful

Why does a product called "Reader" have to process user input?
i discovered a new concept today by circletimessquare · 2010-01-05 05:10 · Score: 2, Funny

the bloatware partisan

--
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
CS4 Scripting too by 0100010001010011 · 2010-01-05 05:11 · Score: 5, Informative

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:PDF forms? DIE! by Qzukk · 2010-01-05 05:17 · Score: 3, Interesting

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.

--
If I have been able to see further than others, it is because I bought a pair of binoculars.
Re:Why not html forms? by jbolden · 2010-01-05 05:21 · Score: 2, Insightful

PDF is a ubiquitous format for which allows for paper like documents which requires only free software. What other format comes close.
HTML = not remotely paper like
forms -> typeset: not ubiquitous
etc...
PDF Javascript vs WWW Javascript by gehrehmee · 2010-01-05 05:37 · Score: 2, Insightful

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?

--
"You know, Hobbes, some days even my lucky rocketship underpants don't help" -- Calvin
Re:Security Not the *Only* Consideration by plover · 2010-01-05 05:39 · Score: 2, Insightful

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 more effective as a security chief if he were truly autonomous, as a CxO is supposed to be.

--
John
Re:PDF forms? DIE! by Volante3192 · 2010-01-05 05:41 · Score: 2, Informative

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.
Re:Why not html forms? by Volante3192 · 2010-01-05 05:49 · Score: 3, Insightful

Except HTML is dependent on margin size, available fonts, interpretation by the browser, too many tiny variables that could cause problems. Most code monkeys can't even check if their stuff works in the browser they use. Binary files like doc can be interpreted wrong if opened in a different program or even version of the same program.
The one thing PDF does well, extremely well, is keep the document the same across platforms. (Better than other options at least.) Use the right tool for the right job: if you need a form to look the same regardless of where it ends up, your best bet is a PDF.
Re:Maybe it's just me by mandark1967 · 2010-01-05 05:52 · Score: 2, Insightful

I think you read a little too much into my post. The application is called Adobe Acrobat Reader, but the quotes from the Adobe rep talk about all sorts of crap that 90% of the users at home do not need, or likely even want. As has been suggested in another post above, they need to make Acrobat Reader do one thing. Read PDFs.
I, personally, do not need the capability of filling out forms nor do I need to submit and route forms. I just need to read a motherboard manual to see some jumper pin-outs and the like. In order to accomplish these types of tasks, I use Sumatra PDF reader.
Removing that java scripting functionality from Reader and putting it into something else, like Adobe's Forms Manager makes sense from a security standpoint as well as a marketing standpoint. If they want to charge a premium for the capability of filling out forms and the like, let them. There are companies/people willing to pay extra for that set of features. It also allows them to make Reader more secure by removing the major attack vector from Reader that is exploited today, seemingly by any script kiddie.

--
Sig Follows: "Suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself." -- Mark Twain
declarative standards-based form validation by leighklotz · 2010-01-05 06:04 · Score: 2, Informative

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, here, and here), server side implementations a la GWT (here and here), and mobile implementations (here).
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.
Re:You're and idiot and don't know what you are... by Anonymous Coward · 2010-01-05 06:07 · Score: 2, Funny

Oh, geeze. Here come the JavaScript faggots, err, fanatics.
I understand JavaScript perfectly. I worked with JavaScript before your father deposited his filthy sperm in your mother's smelly twat.
I've had the misfortune of writing hundreds of thousands of lines of JavaScript code, since it's the "trendy" thing to do (according to all the crap that my manager reads). I know JavaScript inside and out.
Lisp and Scheme (note that their names are not fully capitalized, unless you're a fucking retard) put JavaScript to shame.
And congratulations for throwing out terms you heard in the Introduction to Computer Science course that you flunked out of. When I was in graduate school, I wrote several papers on Hindley-Milner type inference and nondeterministic evaluation strategies (based on the work of Church-Rosser) of lambda expressions. Unlike you, I actually do know what I'm talking about.
So, in closing, fuck off you pathetic little turdworm. Go back to Digg, where you can wait 45 s for each page load, due to the mountains of shitty JavaScript they throw at your browser.
Re:Maybe it's just me by Jeng · 2010-01-05 06:08 · Score: 3, Interesting

To summarize. Perfection is the enemy of the good.

--
Don't know something? Look it up. Still don't know? Then ask.
Re:PDF has forms before Javascript by pclminion · 2010-01-05 06:16 · Score: 2, Informative

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).
Re:How difficult is it to remove Adobe Reader? by Grishnakh · 2010-01-05 06:18 · Score: 2, Interesting

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.
Re:Keep your JS but... by Grishnakh · 2010-01-05 06:32 · Score: 2, Interesting

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.
I'll tell you what Adobe is thinking: if they trimmed down their PDF reader to only do what it needs to, and stopped trying to bloat it up with all kinds of crap that almost no one wants, then they would have a product that no one would want to pay for, because there's plenty of free/cheap alternatives that are better for doing the things that most people do with PDFs. Adobe is a big, public corporation with shareholders to please, and that means that they need higher and higher quarterly profits. Part of achieving that is adding everything including the kitchen sink into Acrobat/PDF to get other dumb corporations to buy their overpriced tools and use them.
Remember, you, some guy on the internet that only uses Adobe's reader and not their content-production tools, are NOT their customer. They don't care if you don't like that their reader is 150MB, because you're not their target market. Their target is some dumb company, or better yet the government, that wants to use their expensive tools to make fancy PDFs, which then require you to download their 150MB reader to use these PDFs in order to file your taxes or work with the DMV.
This is a case study in how Free software many times works much better than corporate-produced for-profit software: for many applications, there comes a time when it's pretty much "done", and no one really wants any more features added. For Free/OSS software, this isn't a problem: the application is mature, and just goes into maintenance mode, and the authors move on to something else unless a bug comes up, or maybe they want to update the UI a little, or whatever. For corporations, this is unbearable: a mature application means no steady stream of new customers, so they need to keep adding crap ("bloat") into it to get people to "upgrade" to the latest version, which they can charge more for. They need to do this so they can have continuously increasing revenues.
Re:How difficult is it to remove Adobe Reader? by Skuld-Chan · 2010-01-05 06:34 · Score: 3, Informative

(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.
Devil's advocate for Javascript by RevWaldo · 2010-01-05 06:38 · Score: 2

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.

--
Prisencolinensinainciusol. Ol Rait!
Yeah, right by Locke2005 · 2010-01-05 06:56 · Score: 2, Insightful

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

--
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Re:How difficult is it to remove Adobe Reader? by jonom · 2010-01-05 10:00 · Score: 2, Interesting

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 electronically.
Why Javascript or any other scripting ability (there's also FormCalc in PDF)? Besides error checking, math and other obvious things - interactivity. I can have the form adapt as it is filled in. Clicked a checkbox that says you're not married and don't have kids? You won't see those kinds of questions later on in the form.
This only scratches the surface - with the full suite of LiveCycle server technology you can do some pretty amazing stuff.