Support JavaScript inside PDFs

[VFDan]

This would allow stuff such as https://cdn.jsdelivr.net/gh/osnr/horrifying-pdf-experiments@master/breakout.pdf to work.

[GitHubRulesOK]

Note that sample does not work in Mobiles, Safari or Firefox PDF.js nor in Acrobat 9 or other PDF Readers it is a CHROME script Proof Of Concept using PDF name for demo in unsecured Chrome (and Edge etc) Script engine.

most PDF readers (besides Adobe Reader) don’t implement most of this stuff. But Chrome does implement JavaScript! If you open a PDF file like this one in Chrome, it will run the scripts...

...custom Adobe JavaScript API has an absolutely gigantic surface area. Scripts can supposedly do things like make arbitrary database connections, detect attached monitors, import external resources, and manipulate 3D objects

Inspect how many HTML web based script files the sample is running live and consider they would all need to be copied to OFFLINE cache when not loaded online.

Note the one and only Issue in the source Repo is

You've done a real service by pointing out that PDFs can contain some real horrors. I now feel some real fear about downloading PDFs. Do you know of a tool that would check a PDF file to see if it contained any of the various forms of executable content you've mentioned?

[VFDan]

There's also https://pspdfkit.com/blog/2018/how-to-program-a-calculator-pdf/ (works in Mobiles, Chrome, Firefox) and https://pspdfkit.com/blog/2019/create-pdf-game-tic-tac-toe-javascript/ (works in a mobile viewer)

[GitHubRulesOK]

There is also https://www.locklizard.com/track-pdf-monitoring/ a variation of https://www.simonewebdesign.it/how-to-create-web-bug-aka-beacon-image/ has been added to pdfs and just like google stats I could see online which page I had read offline or https://www.komando.com/security-privacy/new-adobe-pdf-bug-can-get-you-hacked-with-just-one-click/460762/ or thousands of other ways to use javascript

[VFDan]

There's malicious usage for executables too. Does that mean every system should stop running executables? No, because executables have non-malicious uses too. Same with JavaScript in PDFs.

There could be a warning before JavaScript is ran in the PDF, similar to images in e-mails. (This warning could be turned off in the config)

[GitHubRulesOK]

I use JS daily in Edge PDF browsing / Tracker Xchange XFA Editor etc / Acrobat 3D viewer etc / MuPDF-GL PDF file modifier but have no need for JS whilst everyday fast viewing their slower render printouts.

[VFDan]

Sure, but in the thing I'm distributing it with, those aren't really options. Again, a warning before JS runs would work well.

[dfischer]

Hard pass, please no. Security nightmare.

[Paweth]

Please let there be at least one pdf reader which is secure. Supporting javascript is awful idea - like others already said. I don't get why there is some need for pdf's to have interactivity and other completely unnecessary features that turn them into websites. Pdf's should be pdf's, websites should be websites.

[VFDan]

It very well could just be an opt-in option, and hide it entirely unless it's accepted in the settings.

[Paweth]

I still don't think that implementing that would be good idea - even keeping this as optional. If there is no way to invoke javascript it guaranties that no malicious scripts would be ever invoked. It's the best kind of safety. But if Sumatra would have that option (to invoke javascript) it could very well be exploited by some people as they would write malware targetting it, that could for example change it's settings behind our backs. Not to mention, it's normal for any software to have some bugs. One could for example overwrite settings or make Sumatra not respect disabling javascript. It's just speculation not backed by knowledge (i just use common sense) but I think it's the best to have absolute certainty and not leave room for any risk at all when it's not necessary. And for some fancy features I think it's completely not worth it. Especially when there are other pdf reader alternatives that already support javascript. Why is there need for Sumatra to follow this trend too?

[krystian3w]

If I see correctly pdf.js inside https://github.com/Eclipse-Community/r3dfox/releases disables JavaScript injection.

[GitHubRulesOK]

@krystian3w PDF.js is nothing like chrome (foxit based) viewer which is closer to Acrobat so JS exploits work in Chrome but cannot in Mozilla with SumatraPDF. So when I want to browse dubious Web PDF I use SumatraPDF plug-in not PDF.js

It is not injection you need to guard against with PDF but internal exploit scripts already in the download. SumatraPDF does not run exploits except in CHM (run using Windows) or PS (run with GS)

[krystian3w]

So much for the current sumatra plugin being befuddled without reimplementing NPAPI in Firefox's own compilation.

Which seems difficult since even the co-author is asking for help with this: https://github.com/Eclipse-Community/r3dfox/issues/65

[GitHubRulesOK]

@krystian3w Mozilla up to 125 was accessible

Agreed your suggestion for version 126 by r3dfox is now immune

POCs are usually targeted to a single attack vector so the above does not work in those few remaining browsers including Current Edge that support Acrobat DC, however they can be attacked by Acrobat targeted exploits.

Those same few browsers can run SumatraPDF without fear of exploits as they do not "Function" This one is slightly out of date whereas K-Meleon is a much slower cycle.

Best of those still standing is still ahead of the game so 33.1 is PDF.js uptodate? plus support for Acrobat and SumatraPDF depending on preference.

[maximvoven]

Some Personal Observations: In some circles it is impossible to not run into pdf's containing JS Code. Summarizing some information and gripes that have been shared with me, certain software (Purview, Version Control, etc.) will only create pdf's with the full contents of the pdf's in JavaScript and only viewable in a java script enable pdf viewer (a certain Acrobat), striping out the java script is possible by printing to a file but then the document becomes unsearchable without ocr and difficult to copy paragraphs/tables from.

Why be able to parse JS In a file: Because files like the following exist

• File with indicators if the file is the most up to date version.
• Obscure government form and don't want to bombard the user with lots of unrelated pages
• Your friend created an obscure calculator 15 years ago but only provided in pdf form.

Addressing Security: In my opinion JavaScript in pdf files should be treated like macros in word documents (Per LibreOffice Implementation): Disabled by default Globally, require enabling in settings to make available to option, require per pdf authorization. Like Macros they are liability/legacy feature but the modern world literally does not work without them (For better or for worse)

Foreseen Problems: As others have aluded their are a number of problems. The PDF Javascript standard is not clearly defined, Adding a JS Engine introduces serious risks, Render times/loading times could be impacted detracting from the main thing that makes Summatra a staple pdf viewer.

Why Implement: Its implementation in Sumatra, even a rudimentary one, and one with safeguards described above could be extremely beneficial in expanding the user base and preserving access to legacy documents. This is something that we could all agree is a useful cause.

Afterword: Ill try to hack in a java script component for testing purposes into the pdf render engine, but this type of programing is not my strong suit. If i have any success I will post my fork here.

[GitHubRulesOK]

@maximvoven SumatraPDF is built on MuPDF-GL which will use JS no problem and I asked if there was a switch to stop autorunning contents thus you have to deliberately start that app without JS self running !!, Thus it should be possible to add that ability into SumatraPDF but PLEASE PLEASE ensure it does NOT default start active it will NOT work with Gov/org files as those use ADOBE PROPRIETARY CODING that requires Acrobat Reader with imbedded Adobe editor.

Many Acrobat Reader files do NOT meet the ISO standard for compliant readers.

To run compliant PDF JS automatically active, simply use the system viewer so forms and calc.pdf work in WINDOWS Chromium based Edge, with or without the new Acrobat engine. No need for another exploitable Windows Variant

Works AUTOMATICALLY in MuPDF so 3 + 4 =

[GitHubRulesOK]

Just a comment that SumatraPDF still runs well in 3 modern browsers but JS is thus blocked so secure.

v33.4.0.1 (2024-10-09) This is a small update to address two important issues:

Extension compatibility issues with the ghostbuster (leading to tab handling problems).
Windows 7 compatibility issues in 32-bit builds on some systems (leading to application UI paint failures/black window).

v33.4.0 (2024-10-08) This is a development, bugfix and security release.