Isn't it time we made first messages from all new contacts plain text only, and all other messages some very restricted subset rather than some crazy extensible system that isn't so different from ActiveX?
And on top of that, maybe the whole app should run in a sandbox.
And on top of that, perhaps it should all be a webview to give one more layer of protection.
There is even precedent for doing this seamlessly: the Apple Mail client will not render media from unknown senders without user confirmation. iMessage should have the exact same behavior for the same reasons. It’s frustrating to watch greedy project managers re-learning the exact same lessons that a previous generation already learned the hard way, especially when they all work in the same building.
This is for a different reason (all useful e-mail clients do the same thing!). If Mail (or thunderbird or whatever) loaded the media, then the sender could know you opened the e-mail (by sending each recipient a unique image), leaking information.
Does the Apple Mail client do this for images included with the message (instead of referencing by URL)? Like another comment mentions, this is done for other reasons, and many clients render embedded images by default.
Mail does this for privacy, not security. Emails can load remote content and this can be used to track you. This is not generally true of images sent in iMessage because they get sent directly.
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.
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.
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.)
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
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.)
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.
This is very different from ActiveX. ActiveX had hundreds of exploits widely available freely on the dark parts of usenet, and exploited by every proverbial scriptkiddie in a basement against a swath of computers across the world.
iMessage has had a handful of exploits which are licensed out for extortionate amounts by people like NSO to a very small number of scummy nationstate threat actors in extremely targetted but very high-threat attacks on very high-profile targets.
True but a useless fact. One way to interpret u/seanhunter's comment is to make the comparison between imessage and activex in the known exploit space and then extrapolate into the unknown space assuming equal proportions. Seems reasonable to me.
I really don't think that's true - the state of appsec and security awareness in general has really improved a lot, and all of the major platforms (windows included) are much much more secure now by default than in the activeX era.
It's definitely not the case that anyone can just throw together an iPhone zeroday, which is why the price of these exploits is so much higher.
It means it runs through iMessage. Whether the "turn off iMessage" feature is enough I don't know. But if turning off iMessage actually stops any messages and SMS/MMS etc from running through iMessage at all, it's a pretty decent bet.
What's not clear to me is given all of the layers/security features Apple has, say you are able to get an iMessage exploit where you can run code... you can't access the file system/cache of other apps (like your banking app to get cookies/tokens), can you?
Isn't it time we made first messages from all new contacts plain text only, and all other messages some very restricted subset rather than some crazy extensible system that isn't so different from ActiveX?
And on top of that, maybe the whole app should run in a sandbox.
And on top of that, perhaps it should all be a webview to give one more layer of protection.