A few more words on Acrobat and JavaScript, triggered by a recent report in The Register that Adobe Reader is now the most popular application for targeted malware attacks. At one level this is old news, referring as it does to research done last year by antivirus maker F-Secure, and also somewhat obsolete, as the data, linked below and in the article, pre-date the Adobe 9.13 update referred to in the first post of this blog.

But it is interesting, at least, to learn that the Adobe Reader is now more targeted than Microsoft Word. I believe this status to be a consequence of the trust people put in PDF and Adobe Reader; nobody in their right mind has opened a .doc file from an unknown source in years (and anyone who has used the beta of MSOffice 2010 can tell you that Microsoft is taking that problem seriously). But the key point about this malware issue, from FileOpen's perspective, is that the attacks all target the JavaScript layer in PDF, which is normally suppressed by security handler encryption. In other words, encryption of the type FileOpen offers should be considered a solution to this problem, for several reasons:

• Files encrypted by PDF security handlers do not rely on any JavaScript methods, so disabling the execution of JavaScript via the preferences settings shown in the F-Secure article, http://www.f-secure.com/weblog/archives/00001671.html , will have no impact on the opening or use of files encrypted using the security handler.
• Even if JavaScript is enabled, files encrypted by security handlers (at least those employed for DRM) are normally not vulnerable simply because the permissions required by the JavaScript - i.e. the ability to change the Document - are the very ones that publishers normally use DRM to restrict.

That said, it is probably possible to create a PDF that, after encryption with FileOpen, still executes one of the vulnerable JavaScript functions (getAnnots() and spell.customDictionaryOpen(), see http://www.kb.cert.org/vuls/id/970180 ), but for the exploit to work the publisher would need explicitly to enable modification of the document (a setting that defaults to off in FileOpen software).

Here's a more detailed explanation of what is happening inside the Adobe viewer, for which I'm indebted to Patrick Leckey.  The JavaScript boundary-condition error is setup when the arguments are processed by the code internal to the getAnnots() method.  But the permissions check, by which the Security Handler opens the file and specifies what actions are to be permitted, happens at the JavaScript engine layer - before the getAnnots method is processed internally.

That basically means that when you call getAnnots() in JavaScript, Acrobat passes this request to its JavaScript interpreter.  The interpreter then sees a request for getAnnots() and checks the document permission to see if this method is allowed to be called.  If it is not, it returns a NotAllowedError and halts execution.

The result is that unless the Security Handler, i.e. the publisher, has granted permission to edit the document (specifically,  pdPermEditNotes) the vulnerability cannot execute. For nearly every licensee of the FileOpen software, then, the issue of JavaScript vulnerability in Adobe Acrobat/Reader is a non-issue.