Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can someone explain like I'm 5 why it's so hard to prevent this?

I mean with a messenger app, you know you're getting some payload of data from a specific place, that goes through your own server, and is only ever going to be text or picture or video.

Why can't that be sufficiently sanitised en route and as it arrives to not have this kind of thing happen all the time?



Because the OS is too complicated, imessage is a legacy app which is deeply embeded in the OS. And often the exploits are in things like the notifications but imessage is the easiest way to deliver the data to any ios user.

And people will flame me for this, but part of it is because the language iOS is written in allows these exploits to slip in easily and all over the place and the difficulty of stopping it is too great. There is a good reason Google has started migrating core components of Android to Rust and that the Google security team is pushing the effort for rust in Linux.

The surface area for bugs becomes so much smaller when you can have a compiler eliminate whole classes of bugs.


The language might help the developers mitigate some issues but it is definitely not a solution the bad legacy code, mediocre development and test processes etc.


It isn't a panacea. Switching to Swift or Rust wouldn't prevent all vulns. But it would improve things. Modern code, strong developers, rigorous testing, static analysis, and fuzzing all make things better but they still consistently fail to enable developers to produce programs free of memory errors. This is true even for applications that have absolutely world class people doing these things.

You need all of it. Language safety is only part of the path forward, but it is an essential part.


In theory… Can you name a popular large project or product where memory safety issues have been overcome this way?


TBH you need to combine both, NASA uses safer languages and strict processes for example. Simply moving to another language might mitigate some possible issues but will definitely won't solve everything


End to end encryption. The server doesn't get to see the data, so there is no chance to analyze/filter it on the way. All the parsing and sandboxing has to happen on user devices... and there's always one more bug left to exploit there, especially in a legacy codebase like iMessage.

This is one of the unfortunate downsides of E2EE: there is no way to do server side security on message contents, so you rely entirely on endpoint security. For a non-E2EE service it would be trivial to scan for, collect, and more easily block exploitation attempts.


Hadn’t thought about that! Thanks.


The relevant applications are written in memory-unsafe languages. For an application of meaningful complexity, it is virtually impossible to actually write a safe program in C or C++ and even more impossible to maintain that safety. The code doing the sanitization is itself attackable and the process of sanitizing complex media is very complicated.


I hadn't thought of it this way, of the thing being sent to defend actually being the point of attack - makes sense as a strategy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: