Hacker News new | past | comments | ask | show | jobs | submit
Thaxll | on: Today, we hacked what we'd set out to hack: the iPhone
Is it an exploit around the library that handles PDF parsing/opening? Can someone explain how files / attachement are open on a mobile device ( android/iPhone).

I don't understand how in 2026 this is still a thing, we have many safe languages to parse/deserialize data. Why is it complicated?

drum55 | parent | next
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 | root | 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.
loading story #50212161
loading story #50212021
loading story #50212349
loading story #50212492
loading story #50211977
loading story #50211939
layer8 | root | parent | 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”.

loading story #50212373
Wowfunhappy | root | parent | 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?

loading story #50212598
loading story #50213008
cosmic_cheese | root | parent
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).
loading story #50214702
loading story #50212117
ethin | parent
I'm pretty sure not even the safe languages would help you here. PDF allows you to pretty much run arbitrary code since it supports javascript, images, and a bunch of other things I'm forgetting, and you can't not implement javascript support or otherwise be selective about what you support with it because then all the end-users will complain when they get that one PDF that they need to fill out but it needs JS because... Nobody knows.