| ▲ | drum55 7 hours ago |
| PDFs are basically executables, that's why it's hard. They support running code, they support decoding images which themselves have their own custom compressors that are basically code. Anything to do with image formats is rife for bad decoders, insane compression algorithms from the 90s, and a PDF is basically 1000 formats inside many different container types with executable code plastered on everywhere. If you want to make a compatible PDF viewer you'll need to be able to implement an image decoder algorithm for a fax machine that was specific to Japan in the late 80s, which was somehow ratified into a standard and is used today by all the top legal firms, or something absurd like that. When you open a PDF on your computer, depending on how it is being parsed, it can even make outbound network connections without you knowing. To safely open a PDF you need one of those bomb proof suits, a disposable laptop, and even then you might be going home without eyebrows. |
|
| ▲ | paxy 7 hours ago | parent | next [-] |
| Willing to bet that a default "treat PDFs/documents/spreadsheets as dumb" option in operating systems would eliminate the majority of common one-click vulnerabilies out there. And exactly 0.001% of actual use cases would be affected. |
| |
| ▲ | bradly 6 hours ago | parent | next [-] | | This is one of the things iOS's Lockdown Mode does. I wish the features of Lockdown Mode were able to be enabled individually instead of a single all or none option. https://support.apple.com/en-us/105120 | | |
| ▲ | Gigachad 2 hours ago | parent | next [-] | | I’ve turned on lockdown mode while this CVE insanity is going on. It’s far less disruptive than I expected. The only thing I noticed missing is web gl is disabled. | |
| ▲ | kccqzy 5 hours ago | parent | prev [-] | | Your link doesn’t say anything about PDFs. And if I remember correctly it only disables PDF previews in Messages. This means if you have a zero-click exploit now it becomes a one-click exploit. I fail to see how that’s relevant given the article is already demonstrating a one-click exploit. |
| |
| ▲ | nhubbard 7 hours ago | parent | prev | next [-] | | PDFs are just absurdly complicated in general. Dumbing down the parser might be the right idea. I wonder what consequences that would have with how intertwined PostScript and PDF in general are with macOS/iOS; maybe that's why the PostScript engine was removed with macOS Sonoma/iOS 17? I don't know if that was only user facing behavior and Apple is still working to remove the internal usages. | |
| ▲ | kccqzy 6 hours ago | parent | prev | next [-] | | No. Very few PDF exploits come from the officially sanctioned way of running code (JavaScript) inside PDF. Most are just plain old parser bugs. | |
| ▲ | wildzzz 6 hours ago | parent | prev | next [-] | | That's kind of what Adobe does with downloaded PDFs, you have to click the Enable button to turn on more document features. My schematic capture app will output a PDF that has links that will take you to specific spots on a page and also some JavaScript where you can right click on a part and see it's BOM information. None of that stuff works until you click the Enable button. I've also seen some vendors offer not only normal 3D model files and 2D drawings but a PDF that has an interactive 3D model inside. It's kinda cool how much random shit can go into a PDF but it's clearly a massive malware vector. One neat thing I've seen is a PDF that will ping an IP catcher when opened in Adobe, regardless of the security level. The same can be done with word docs, excel spreadsheets, and even SVGs. | |
| ▲ | dylan604 7 hours ago | parent | prev | next [-] | | Did we do that with Excel spreadsheets so that macros are disabled by default? | |
| ▲ | Vaushite 7 hours ago | parent | prev [-] | | "dumb" isn't a real thing in computer science though. You mean render them to bitmaps in a sandbox? | | |
| ▲ | nananana9 6 hours ago | parent | next [-] | | I read it more as "don't implement JS, 3D object rendering, slideshow transitions, sound annotations and the other 999 insane features that I'm not even aware exist" | | |
| ▲ | odo1242 6 hours ago | parent [-] | | Would require defining what features are needed. "Require PDF/A" is probably a reasonable approximation, though it would break most PDFs |
| |
| ▲ | Melatonic 6 hours ago | parent | prev [-] | | I think he just means disable any of the "advanced" features mentioned above like accessing web content, running custom scripts, etc etc. You might still be vulnerable to any dependencies they use for image rendering itself but I bet it would make it drastically more safe. Then just have a button for turning those on as needed on a case by case basis | | |
| ▲ | Vaushite 6 hours ago | parent [-] | | If you disable features then people will see important documents as white rectangles and complain and you'll get a reputation as not working. | | |
|
|
|
|
| ▲ | layer8 7 hours ago | parent | prev | next [-] |
| > PDFs are executables, that's why it's hard. That isn’t really true, it’s not hard for PDF viewers to block by default (or just not implement) the problematic features, which also aren’t critical for the vast majority of PDF files. The exploitable bugs are typically the usual, some buffer overflow in an underlying image or font library or similar, but unrelated to PDFs being “executable”. |
| |
| ▲ | pishpash 6 hours ago | parent [-] | | What a sleight of hand. PDF's are obviously not executable, any more than text files are. Decoders are executable and they can choose to unsafely handle input. Even plain text editors can have exploits. It's no different than any piece of complex software. | | |
| ▲ | layer8 6 hours ago | parent [-] | | The characterization of the PDF format specifically being “basically code” in any substantial manner is simply incorrect. The only PDF-specific features that reasonably meet that description is the PostScript support, which has fallen out of use decades ago and was completely removed in PDF 2.0, and the JavaScript support, which is optional, prohibited in PDF/A, and can easily be limited or omitted by a PDF viewer. | | |
| ▲ | jwilk 5 hours ago | parent [-] | | > the PostScript support What do you mean by that? | | |
| ▲ | 0x457 3 hours ago | parent [-] | | Older PDFs support PostScript XObjects: literal embedded PostScript code. Not sure it counts tho, because IIRC it was never executed by PDF viewer itself. It was "gives this to printer when printing" |
|
|
|
|
|
| ▲ | Wowfunhappy 6 hours ago | parent | prev | next [-] |
| > PDFs are executables, that's why it's hard. They support running code I don't think Apple's PDF renderer supports e.g. running JS, you'd need real Acrobat for that. Or are you talking about something else? > they support decoding images which themselves have their own custom compressors that are also basically code themselves. But this is fundamentally true for anything that displays images, right? Or are the PDF formats particularly bad for some reason? |
| |
| ▲ | wildzzz 6 hours ago | parent | next [-] | | Yeah a lot of those fancy PDF features are Adobe-only. It's not that other apps can't support those features, it's that no one in their right mind wants to spend endless amounts of money and time trying to sandbox it. Most people have some understanding that shady websites can give you malware, a drive-by exploit is pretty rare but it's good that most people think just visiting a site could infect your computer. But a PDF is just a document, right? Just thinking that a PDF is just words on a page is exactly why it's such an insidious threat. Or they'll get a PDF as an email attachment, see that it's not an exe or something weird, and open it because they think a document is safe. | |
| ▲ | ethin 5 hours ago | parent | prev [-] | | I think it's more the image formats PDF supports? I could be wrong, but there was that forcedentry vulnerability (which was insanely cool, even if really bad) |
|
|
| ▲ | cosmic_cheese 7 hours ago | parent | prev [-] |
| From the standpoint of a layman it looks like there's a lot of overlap between writing safe web browsers/engines and writing safe PDF readers/engines. There just hasn't been anywhere near as much of an impetus to push PDF readers/engines in that direction because most of us aren't interacting with PDFs nearly as often as we interact with the web (and things built on web tech). |
| |
| ▲ | layer8 3 hours ago | parent | next [-] | | The difference is that web browsers absolutely need to support JavaScript to correctly display many important web sites, whereas that’s not necessary for PDF. You also don’t have to deal with vulnerability footguns like XSS/CSRF/CORS in PDF. Except for some rare special use cases that PDF viewers don’t need to support, nothing has to happen online for PDF. It’s really not comparable. | |
| ▲ | Melatonic 6 hours ago | parent | prev [-] | | Most web browsers actually make decent PDF viewers by default don't they ? |
|
