| ▲ | aemoron 6 hours ago |
| 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... |
|
| ▲ | enjoytheview 6 hours ago | parent | next [-] |
| 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. |
|
| ▲ | motoboi 6 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | anthk 6 hours ago | parent [-] | | That's why you need Rust in any image decoder. FFMPEG too. | | |
| ▲ | steve1977 5 hours ago | parent | next [-] | | 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. | | |
| ▲ | motoboi 3 hours ago | parent | next [-] | | They probably link libraries written in C, given the scope of the pdf and image parsing. | |
| ▲ | frizlab 5 hours ago | parent | prev [-] | | It mostly is. Has pretty much caught up with all of rust actually (while being much more readable). |
| |
| ▲ | NetMageSCW 5 hours ago | parent | prev [-] | | Rust is not a magic security wand. | | |
| ▲ | gejose 5 hours ago | parent | next [-] | | 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... | | |
| ▲ | anthk 5 hours ago | parent [-] | | 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. | | |
| ▲ | nkjoep 4 hours ago | parent [-] | | What folks at Ladybird did this year. Started adopting rust for part if not all their engine. |
|
| |
| ▲ | mr_toad 3 hours ago | parent | prev | next [-] | | No, but it was created to mitigate these sorts of risks. | |
| ▲ | wat10000 2 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | anthk 5 hours ago | parent | prev [-] | | 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. |
|
|
|
|
| ▲ | tech234a an hour ago | parent | prev | next [-] |
| 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). |
|
| ▲ | creata an hour ago | parent | prev | next [-] |
| 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? |
|
| ▲ | midtake an hour ago | parent | prev | next [-] |
| Does Lockdown block all PDFs? |
| |
|
| ▲ | mahboi 6 hours ago | parent | prev | next [-] |
| Well it was TIFF one time |
|
| ▲ | dpacmittal 44 minutes ago | parent | prev | next [-] |
| pdf is the new swf |
|
| ▲ | NetMageSCW 5 hours ago | parent | prev | next [-] |
| Never mind - that only applied to origins PDF 1.x. |
|
| ▲ | bushbaba 6 hours ago | parent | prev [-] |
| Maybe with LLMs a full rewrite that’s more secure could be done |
| |
| ▲ | ASalazarMX 5 hours ago | parent | next [-] | | 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. | | |
| ▲ | jitl 5 hours ago | parent [-] | | > 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. | | |
| ▲ | Someone 3 hours ago | parent [-] | | > 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. |
|
| |
| ▲ | dgellow 5 hours ago | parent | prev [-] | | A full rewrite of what? iOS? I hope you’re kidding | | |
| ▲ | anthk 5 hours ago | parent [-] | | Apple can rewrite the media and PDF libraries in no time in Swift/Rust, they have tons of money to waste. | | |
| ▲ | doc_ick 3 hours ago | parent [-] | | 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. |
|
|
|
