What's with iOS and pdfs pwning them? Reminds me of the ForcedEntry in Pegasus.
https://projectzero.google/2022/03/forcedentry-sandbox-escap...
https://www.trendmicro.com/en_gb/research/21/i/analyzing-peg...
https://projectzero.google/2022/03/forcedentry-sandbox-escap...
https://www.trendmicro.com/en_gb/research/21/i/analyzing-peg...
Or just spend a few billion tokens rewriting the whole chain in a memory safe language. This nonsense is inexcusable in 2026
Re security, there are many pdf viewers, so the rewrites exist, and some of them do not have the js execution engine and all that jazz that opens up all sorts of potential exploits.
it's a feature. expect next exploit to also be pdf or image related.
PDFs may need to be further forwarded or edited on user's machine(s). Doing this in VM might save your device, only to pass the problem further down the road to a more vulnerable system.
The safe thing to do is to disarm the file - convert it in a blast proof VM. The conversion can and probably should be further tuned to explicitly disable some of the crazier, more moronic features of the format, sacrificing compatibility for safety. The same should be done with all other binary formats. It costs next to nothing, considering how crazy OP are today's phones. I wonder why it has not been done yet.
The other problem: I am not 100% sure if a clean rewrite would yield a safe viewer. As others have mentioned, PDFs can contain scripts. You'd always have to run them in VMs.
So pdf and images are the best vector for iPhones.
Once you escape the parser you have to reach and escape the sandbox and from there reach the kernel.
"~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" - Microsoft [1]
"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code." - Google on Android [2]
This is also worth looking: https://www.chromium.org/Home/chromium-security/memory-safet...
References: 1. https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactiv... 2. https://blog.google/security/rust-in-android-move-fast-fix-t...
They don’t seem convinced that that would be a meaningful use of time for them. (2025)
https://itsfoss.com/news/ffmpeg-swipe-at-rust/
And 6 months ago someone did a little experiment using Claude to rewrite FFmpeg in Rust. It was by the own description by the person that had the AI do it, significantly slower than FFmpeg even when incorporating assembly code from FFmpeg.
https://github.com/sharifhsn/wedeo
Maybe with further advancements it is now possible to get a better result, or soon.
But if you are going to copy their assembly code into the Rust protect how do you definitively prove that no memory unsafe operations are happening in those parts? Seems to me that either the whole thing should be safe Rust, if the point of the rewrite is memory safety.
On less powerful machines, dear Mutt+isync+msmtp users like me, please use AERC (written in Go) against these. It's slower, but far more secure than C. Also, SLRN needs a Go rewritten clone (able to point to slrn's caché) like nothing else. Comp.misc and comp.arch still are extremely valuable.
You certainly can still write security vulnerabilities that don't involve memory safety violations, and these languages always have unsafe escape hatches that you can use to shoot yourself in the foot. But as long as you don't just sprinkle unsafe on everything, using a safer language is going to make a ton of vulnerabilities just disappear.
Looking at the issues from this past week, safe languages won't stop you from using 4 as your private key, but they would have entirely prevented the PHP vulnerability.
The best solution would be ditching it completely for a simpler subset of features. But that will never happen.
Like the saying goes:
Everyone uses only 20% of the features, but it's a different 20% for different people.
We are running a service which collects documents from our consumers. We have a content disarm service which is basically a blast-proof container without any access rights, fed a stream of source bytes and outputting clean PDFs. Not a month passes without a burst of attempts at poisoning our systems with malicious PDFs. I don't remember when was the last time that we had attempts driven by malicious jpegs or pngs, just PDFs. Its one of those uber-shit Turing-complete file formats that should die long ago.
Who am I kidding, I think the PDF format will outlive us.
if apple parsed pdf with (js, swift, rust) none of this would be possible. the problem is memory-unsafe code.
Interpreters and compilers can have bugs. Bugs can cause memory safety issues.
Rust is interesting because it’s a low-level language with strong memory safety. That makes it a good fit for projects like coreutils. I’d argue it makes it a bad fit for many other projects that get rewritten in it, though. Not everything actually needs to be in a low-level language with compile-time memory management.
They have the means, they have the motivation
Lately they have fewer and fewer excuses not to