Comment by motoboi
16 hours ago
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.
They probably link libraries written in C, given the scope of the pdf and image parsing.
It mostly is. Has pretty much caught up with all of rust actually (while being much more readable).
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.
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...
2 replies →
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.