Hacker News Reader

Comment by devttyeu | Hacker News Reader

And after all that hardcore engineering work is done, iMessage still has code paths leading to dubious code running in the kernel, enabling 0-click exploits to still be a thing.

View on HN

That's one way to look at it, but if perfection is the only goal post then no one would ever get anywhere.

What's the dubious code?

Running something in the kernel is unavoidable if you want to actually show stuff to the user.

In ~2020, it was:

Attacker sends an imessage containing a PDF

imessage, like most modern messaging apps, displays a preview - which means running the PDF loader.

The PDF loader has support for the obsolete-but-part-of-the-pdf-standard image codec 'JBIG2'

Apple's JBIG2 codec has an exploitable bug, giving the attacker remote code execution on the device.

This exploit was purchased by NSO, who sold it to a bunch of middle eastern dictatorships who promptly used it on journalists.

https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

None of that ran in the kernel. Everything happens within a single process up until the sandbox escape, which isn't even covered in your article. The article's sequel* goes into detail about that part, which involves subverting a more privileged process by exploiting logic errors to get it to execute code. The only involvement by the kernel is passing IPC messages back and forth.

* https://googleprojectzero.blogspot.com/2022/03/forcedentry-s...

Disable iMessage via Apple Configurator MDM policy and enable Lockdown Mode.

I imagine the latter is sufficient.

PS: make sure you remove that pesky "USB accessories while locked allowed" profile that Configurator likes to sneak in.

Need an open-source MDM profile policy linter.

Why would a nation-state actor need access to your kernel when all the juicy stuff[0] is in the iMessage process it's already loaded into?

[0] https://xkcd.com/1200/

Reply on news.ycombinator.com