3 ms·

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 supp

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.