Adobe's rich JavaScript bankrupts security

Summary:In the past week, the security environment around Adobe's Reader and Acrobat products has imploded, with yet more JavaScript vulnerabilities appearing. Adobe needs to look no further than Microsoft for a lesson in how to deal with these situations.

In the past week, the security environment around Adobe's Reader and Acrobat products has imploded, with yet more JavaScript vulnerabilities appearing. Adobe needs to look no further than Microsoft for a lesson in how to deal with these situations.

No other company is able to say that they have graduated from the Security School of Hard Knocks like Microsoft. And the JavaScript vulnerabilities we see now are comparable to the problems seen with Excel and macros in the past.

This situation is typical of much of Adobe's modus operandi for software: pack the applications so full of features and turn the majority of them on by default such that the application comes to be regarded as bloated and slow. It's little wonder that Adobe Updater is always interrupting workflows when it has to check for the kitchen sink and then some.

The key to my bemusement is the reasoning for why a PDF reader should have a JavaScript engine turned on by default in the first place. Surely it makes more sense to invoke the engine when needed via a user prompt — at least the user would be aware that a particular PDF is trying to do more than be a simple postscript file. Adobe would do well to have a prompt on rich PDFs that is similar to Excel's macros prompts.

Unfortunately at the present time, the only proper workaround is this Adobe-endorsed solution to turn off JavaScript wholesale. Once this is done, authors of PDFs are able to make an API call to prompt the user to turn JavaScript back on. If the user ignores the prompt or the PDF author does not make the proper request, then nothing may be displayed at all, depending on how rich the PDF is. Alternatively, leaving JavaScript turned on will not stop malicious code running at all — you might not even be aware that it is running.

Frankly this is completely sub-optimal. Users should be aware that a PDF is trying to use JavaScript each and every time a PDF is opened that requires it. As most PDFs we encounter are not rich, having JavaScript enabled by default is a waste of resources and a juicy back-door waiting to be exploited.

It's a good thing that rich PDFs have not taken off like Adobe hopes they will, otherwise instead of a minor annoyance it could be show-stopping.

Hopefully the company will be able to update all affected products and make the correct design changes now while the problem is still small.

In the meantime, I'm sure Foxit Reader will enjoy all its new users and OS X/Linux users will be thankful for built-in readers that are typically "good enough".

Topics: Security, Apple, Linux, Microsoft, Open Source, Operating Systems, Software Development, Windows

About

Chris started his journalistic adventure in 2006 as the Editor of Builder AU after originally joining CBS as a programmer. After a Canadian sojourn, he returned in 2011 as the Editor of TechRepublic Australia, and is now the Australian Editor of ZDNet.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.