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...
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...
PDF has been an entry point since forever, it is extremely complex and can in some cases even run javascript, it has a huge attack surface.
Why can't Apple just sandbox the damn thing? Run the renderer in a VM, call it a day.
Or just spend a few billion tokens rewriting the whole chain in a memory safe language. This nonsense is inexcusable in 2026
I sincerely believe you need much more than one billion tokens to rewrite the entire PDF dependency stack in a memory safe language. I think you underestimate how many features PDF has.
I wish that Apple today was a little more like the Apple that ruthlessly murdered the floppy disc and Flash.
Seriously though, I wonder why nobody really attempted to dethrone PDF yet. How hard can it be (famous last words) to design a document format that allows what people generally expect from a PDF, but without the multimedia and interactive parts that are dangerous?
Because the dangerous parts are not the multimedia and interactive parts. These parts are rarely used. Even if you remove these parts from your PDF reader it’s not a meaningful security improvement. Almost all exploits are in the boring 2D text/graphics/images parts.
Network effect. Most documents are PDF. You would need at least backward compatibility, which would mean opening doors to the existing problem.
Firefox has been working on this and are making good headway over the last few years.
It's sandboxed, not in a VM but using the *OS sandbox/seatbelt. Running all renderers in a separate VM on a consumer phone sounds like a terrible time when you need to stay competitive regarding performance, responsiveness, etc.
it offers just enough cover and deniability. Q.e.d this sub thread.
it's a feature. expect next exploit to also be pdf or image related.
The sandbox is just another layer
A bulletproof vest is just another layer.
Too huge attack surface. Good candidate for victim trust (who would not open a pdf file on an iPhone?).
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.
That's why you need Rust in any image decoder. FFMPEG too.
Apple has been propagating Swift for more than a decade now and at least in theory, it should be on par with Rust in terms of safety I'd say.
It mostly is. Has pretty much caught up with all of rust actually (while being much more readable).
They probably link libraries written in C, given the scope of the pdf and image parsing.
The problem here is that pdf is over bloated with features and without strictly defined standard. Rust can't help you with that, or any language for that matter. It's akin to upgrading the security system on a house on fire.
The best solution would be ditching it completely for a simpler subset of features. But that will never happen.
> 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.
Rust is not a magic security wand.
It might not be a magic security wand, but so many critical vulnerabilities in software trace their origins to memory unsafe code and things like "use after free".
"~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...
In case of ms it's often concurrent userland-kernel transitions, and kernel doesn't control how and when they happen. Copilot is busy optimizing windows 11 and can't riir the kernel.
If I were Google I'd try to rewrite Chromium in Rust. The FFMPEG folks should try porting the whole codebase to Rust too. They can always keep the legacy versions for legacy computers (my old n270 netbook can barely play 720p@30FPS anyway, and it's too slow to downsize 4k video to 720 or 480p...), so a bigger amd64 machine will always be -reallistically- needed for anything else than <=720p consumption.
> The FFMPEG folks should try porting the whole codebase to Rust too.
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.
What folks at Ladybird did this year. Started adopting rust for part if not all their engine.
They didn't enumerate everything you need, nor did they say Rust was a magic security wand. Cast your gas somewhere else.
"Seatbelts don't solve car crashes so there's no need to wear one!"
No, but it was created to mitigate these sorts of risks.
It kind of is, as is any other memory safe language.
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.
It cuts down most of the crap trying to trash your machine's RAM (virtual memory in the end, but today it's almost as if you didn't have a MMU). It's good enough.
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.
If it wasn't PDF it'd be something else. It's everything after the PDF that's alarming here - how did they break out of the app sandbox?
I wonder if pdf.js would be more secure since it runs inside a webpage and can benefit from the browser sandboxing. Though I guess iOS has generally managed to keep most of its apps native rather than web app wrappers (as has happened on Windows).
Well it was TIFF one time
TIFFs were used as part of a PSP jailbreak as well iirc
Never mind - that only applied to origins PDF 1.x.
Does Lockdown block all PDFs?
No, it doesn't.
pdf is the new swf
Incidentally, both created by Adobe.
macromedia has entered the chat.
Maybe with LLMs a full rewrite that’s more secure could be done
LLM and full rewrite are a recipe for cooking something that still has flaws but also doesn't work that well. The root cause is that PDF is an old format from a more innocent era. A new document standard that keeps up with the technical and security advances, learns about the lessons PDF taught us, and allows for easy conversion from old PDFs, would be the ideal solution.
Who am I kidding, I think the PDF format will outlive us.
> PDF is an old format from a more innocent era
if apple parsed pdf with (js, swift, rust) none of this would be possible. the problem is memory-unsafe code.
Since when was javascript memory safe
> if apple parsed pdf with (js, swift, rust) none of this would be possible
Interpreters and compilers can have bugs. Bugs can cause memory safety issues.
A full rewrite of what? iOS? I hope you’re kidding
Apple can rewrite the media and PDF libraries in no time in Swift/Rust, they have tons of money to waste.
In no time? What are you talking about? It’d take months even with llms for it to be fully polished and tested if they started now.
If anybody has the resources to do it, tho, they do
They have the means, they have the motivation
Lately they have fewer and fewer excuses not to
That is magic thinking and even religious
That is essentially "in no time" on Apple's release cadence.