3 ms·

I understand the motivation, but IMHO a PDF should be a static document, hence, something you can trust without worrying. Since they can contain code, they can

I understand the motivation, but IMHO a PDF should be a static document, hence, something you can trust without worrying. Since they can contain code, they can carry malicious code. PDFs have, in fact, been used for exploits. Meaning that you shouldn't really trust them. Which is a shame.

Thorrez 3y ago
Iphones don't support JS in PDFs, but yet an integer overflow in image decompression code led to a zero-click imessage exploit.[1] So lack of explicit code support doesn't mean you can trust without worrying. Bugs can be anywhere. Iphones have been known to have crash-causing bugs in unicode-handling code.[2] So even just text could be a problem. Disclosure: I work at Google but not on Project Zero. [1] https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... [2] https://techcrunch.com/2018/02/16/iphone-bug-telugu-unicode-ios-mac-text-bomb/ https://techcrunch.com/2018/02/16/iphone-bug-telugu-unicode-...
- AlotOfReading 3y ago
  That's true, but it misses the point that scripting adds orders of magnitude greater complexity to the attack surface. Fixing other kinds of bugs is fairly straightforward. Update your toolchain, update your dependencies, use the right dependencies, avoid undefined behavior, etc. Fixing scripting issues means participating in an active arms race.
- Karellen 3y ago
  > Bugs can be anywhere. Yes. Bugs. Bugs can be fixed. By-design (mis)features can't be fixed. The only way to fix them is by removing the feature. Unless you're agreeing that JS-in-PDFs is a bug, you're conflating fundamentally different issues.
  - tredre3 3y ago
    JS in PDF might be a mis-feature, but any security lapse is indeed a bug in the implementation (made doubly worse by firefox running the JS in a web context). Yes, removing JS support would get rid of potential security exploits. It doesn't change the fact that said exploits rely on bugs in the implementation.
bee_rider 3y ago
There does seem to be a mismatch between what PDFs are mostly used for, and their full capabilities. IMO it’s be nice to define a file format for PDFs main use (I think?), papers and documentation. PDF, scripting, but maybe the ability to zoom and pan figures?
- layer8 3y ago
  Such a format exists and is called PDF/A: https://en.wikipedia.org/wiki/PDF/A#Description https://en.wikipedia.org/wiki/PDF/A#Description PDF viewers can have a matching PDF/A mode where all non-PDF/A features are disabled.

Thorrez 3y ago

Iphones don't support JS in PDFs, but yet an integer overflow in image decompression code led to a zero-click imessage exploit.[1] So lack of explicit code support doesn't mean you can trust without worrying. Bugs can be anywhere. Iphones have been known to have crash-causing bugs in unicode-handling code.[2] So even just text could be a problem. Disclosure: I work at Google but not on Project Zero. [1] https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... [2] https://techcrunch.com/2018/02/16/iphone-bug-telugu-unicode-ios-mac-text-bomb/ https://techcrunch.com/2018/02/16/iphone-bug-telugu-unicode-...

AlotOfReading 3y ago
That's true, but it misses the point that scripting adds orders of magnitude greater complexity to the attack surface. Fixing other kinds of bugs is fairly straightforward. Update your toolchain, update your dependencies, use the right dependencies, avoid undefined behavior, etc. Fixing scripting issues means participating in an active arms race.
Karellen 3y ago
> Bugs can be anywhere. Yes. Bugs. Bugs can be fixed. By-design (mis)features can't be fixed. The only way to fix them is by removing the feature. Unless you're agreeing that JS-in-PDFs is a bug, you're conflating fundamentally different issues.
- tredre3 3y ago
  JS in PDF might be a mis-feature, but any security lapse is indeed a bug in the implementation (made doubly worse by firefox running the JS in a web context). Yes, removing JS support would get rid of potential security exploits. It doesn't change the fact that said exploits rely on bugs in the implementation.

bee_rider 3y ago

There does seem to be a mismatch between what PDFs are mostly used for, and their full capabilities. IMO it’s be nice to define a file format for PDFs main use (I think?), papers and documentation. PDF, scripting, but maybe the ability to zoom and pan figures?

layer8 3y ago
Such a format exists and is called PDF/A: https://en.wikipedia.org/wiki/PDF/A#Description https://en.wikipedia.org/wiki/PDF/A#Description PDF viewers can have a matching PDF/A mode where all non-PDF/A features are disabled.