Hacker News Reader

Comment by alkonaut | Hacker News Reader

Yeah I can't believe we are still seeing this happen over and over again. Whenever you see "zero click" you know it's one of the complex payloads like images, fonts. The answer shouldn't be "don't render images". We should be able to trust that a component that parses external data such as an image, simply can't do anything malicious regardless of input.

If that means sandboxing, fine. If it means having to rewrite all the image parsers from the ground up in a safe language or formally prove them correct, fine. Just get on with it. Apple is rich enough to be able to run their own space program ten times over, I think they could write provably correct imaging libs too.

View on HN

Yes parsers are already sandboxed, and violating the sandbox boundary is where the actual valuable exploit is. Parser vulns are near worthless without the rest of the chain building on it, and the millions of man-years it would take to re-write every last one of them as "provably correct" is better spent hardening sandbox and privilege boundaries.

Which is a completely different problem than simply rewriting things in a safe language.

What is the cause of the sandbox escape in this case? Somewhere (too high in the stack) there is a C-ish program where someone does pointer arithmetic or an array deref in C which is the same thing.

Are you asking what the full exploit chain is here specifically? Because that obviously hasn't been written up yet.

But for the last one, it's the difference between https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... (parser vulnerability leading to not-really arbitrary code execution and memory corruption) and https://googleprojectzero.blogspot.com/2022/03/forcedentry-s... (logic errors leading to a sandbox escape) Notably, the sandbox escape itself did not do anything that would have been prevented by a memory safe language.

The security model of a sandboxed process is that even full arbitrary code execution cannot do anything the sandbox says the process cannot do, and the process the parsers run in is sandboxed to only be able to communicate to other processes through very limited interfaces that have no access to network or disk.

Rewriting would introduce new bugs; it would take a large number of engineering hours away from delivering shiny new things; and a formally correct version would probably be less power-efficient.

It won't happen because these targeted attacks don't affect the bottom line whatsoever. Nobody is switching to Android just because a journalist or NGO employee occasionally gets pwned.

It doesn’t really matter if there are 100 new bugs for every memory unsafety bug fixed. Those new bugs in an image codec would be hangs/crashes or incorrect rendering and that’s it. And that might be serious but it’s not a security vulnerability.

Your problem isn't the quality of your own code, it's that Google exists and is unable to stop their employees from doing stupid things like inventing WebP, because now you need to support WebP too which means using their code to do it.

(Worse, WebP is at least two completely different formats - the lossless mode has nothing to do with the lossy mode.)

I think Apple should either sandbox or reimplement even the most complex formats. Video formats might be painfully complex to implement, but to avoid zero-click you don't even need to safeguard the whole process. You stop autoplaying and you ensure the safety of the parts that parse the metadata/thumbnails required to show the preview. Then worst case you have at least a 1-click threat when someone plays the video which then calls into some 3rd party code.

I think that:

a) Google should be doing that in a memory safe language, kinda nuts that they haven't started doing that already

b) Apple could definitely write their own? Unless I'm missing something crazy here, it seems like they could burn 8 figures and just have their own implementations that are safe

If you reimplemented it they'd just change it. It's Google, they can't stop themselves.

I don't believe you, frankly. I don't believe that Google makes breaking changes to existing image formats often.

They already did - WebP added a lossless mode and VP8 was updated to VP9.

Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)

Are those breaking changes? I'd assume that a decoder would continue to work, just would not support the lossless mode/ VP9.

It will work on old files (since they've already been encoded) but not on new files with the same file extension, and not on, say, YouTube.

Interesting, thanks.

As opposed to Apple’s formats, for which the parsers are definitely less buggy and likely to be hacked.

Reply on news.ycombinator.com