> PDF forms now support JavaScript embedded in PDF files. Some PDF forms use JavaScript for validation and other interactive features.
The amount of complexity that one can put into a PDF is both surprising and a tad frightening.
The amount of complexity that one can put into a PDF is both surprising and a tad frightening.
Adobe had to update reader back in like... 2008?... to prompt before loading external resources. Because companies were embedding Google Analytics into PDFs.
Wow! This is daft. Thank the FLOSS gods for things like Pi-Hole because I never realised this. And if I hadn't blocked Google Analytics there, this would have been a sad state of affairs.
Can't edit my comment any more, but I realise this is quite dismissive of the work the real maintainers have put in. So I'll thank them instead!
[0] https://www.cs.odu.edu/~zeil/cs390/latest/Public/turing-comp...
Though I'm not entirely convinced they haven't accidentally added Turing completeness back in at some point.
I mean you don't really need all that much to write a basic lisp interpreter.
The PDF layout language isn't Turing complete on its own.
Basically, it was a PDF full of scripting and options and such, that let you:
* Choose which content you wanted to use (i.e. content from which sources) * Choose which rules you wanted to use (in case you wanted to use optional rules) * Choose your class, race, and background, and handle them appropriately * Level up your character, prompting you to choose spells, feats, abilities, etc. from every option available to you based on your current character options * Manage your inventory * Import and export your character data * Import and export source data
It was pretty insane. Granted, it was also insanely slow (presumably due to limitations of what data you can store in a PDF and how), but for a bunch of tech-savvy newbies to 5th edition D&D, it was vastly better than the other options and helped us discover a lot of character features that we'd missed when overwhelmed at first.
I still wish they'd put it into literally anything more performant, like an electron app or something. Yes, it was that bad.
It isn't expensive, it is just something to be aware of.
On the flip side, are there any examples of PDF JS being actually useful and not a vector for tracking/exploits?
This issue makes it seem that Components.utils.Sandbox is used when included in firefox, which would be the browser's own JS engine (but confined to a sandbox), and quickjs in other settings (say a website). https://github.com/mozilla/pdf.js/issues/12487
But I can't find Components.utils.Sandbox being referenced in the code on github. So maybe they decided to use quickjs for all use cases? The issue with quickjs is that it's written in C which is an unsafe language. wasm has bad binary security [0] so exploits are easier to create given some memory safety violation. The environment that calls the wasm is extremely privileged compared to random websites, so if a wasm exploit could convince the environment to do something, it would be major trouble.
[0]: https://www.usenix.org/conference/usenixsecurity20/presentat...
{ "policies": { "PDFjs": { "Enabled": false }, "DisableBuiltinPDFViewer": true } }
See:
https://support.mozilla.org/en-US/kb/managing-policies-linux...
I looked at the source code briefly and it's on the order of 10K lines of Javascript.
Just add a couple of lines of js for DOOM in the browser, now in js in a pdf in a browser!
off-topic, but fwiw: the pocorgtfo16.pdf[1] is a polyglot that is valid PDF, a ZIP archive, and a Bash script that runs a Python webserver which hosts Kaitai Struct’s WebIDE which, allows you to view the file’s own annotated bytes.
I thought they always required JS to be enabled. I have JS disabled by default in uBlock Origin, and the inbuilt Firefox PDF viewer doesn't work unless I whitelist and enable JS temporarily for the page. Only then can I read my PDF.
This new feature means you can run JS embedded in PDF… in PDF.js.
Certainly nothing will go wrong here.
Zero websites automatically get JavaScript access from me, and many other savvy web users.
If PDFs are not subject to these same controls in Firefox, then this could be a security and privacy vulnerability.
Even if this weren't true, it would still be false that "all websites already use JavaScript".
Does the JS run in a true sandbox? Inside, outside, or beside the usual browser sandbox? Are network requests allowed? Filesystem access? Are granular permissions required/available?
I want to block JS in PDFs, by default, like I do in web pages.
I'd also be happy to hear that the JS runtime in PDFs is run in a tight document sandbox, operates only on a highly constrained DOM-equivalent, and has zero network or filesystem access. Seems reasonable.