3 ms·

You act like it’s trivial to fix. They’ve already sandboxed the parsers (which this exploit appears to bypass, crashing MessagesBlastDoorService) which massivel

by wepple 4y ago

You act like it’s trivial to fix. They’ve already sandboxed the parsers (which this exploit appears to bypass, crashing MessagesBlastDoorService) which massively drives the effort up. They also had to bypass pointer authentication. Whilst, yes, you can wonder why it isn’t all rewritten in swift (if it isn’t already), exploits will continue to be found and exploited, forever.

tialaramex 4y ago
It arguably is trivial to fix, if you prioritise fixing this. If you say OK, we want to offer safety first and features are only a nice-to-have, you can make that happen. Apple have as usual decided that nope, some of their features are a must have and if safety has to be sacrificed to get features well, sucks to be you getting exploited. Something like Swift isn't up to it. It's less easy to blow your foot off than if you wrote C++ but necessarily (as a general purpose language) you can do it. But what if we give up generality? Languages like WUFFS give up general purpose programming, solving only a narrow problem but doing so with cast iron safety because they're able to prove the system always has valid state. This is entirely appropriate when (as so often) we didn't really need generality, which means having it is a gift for bad guys. "Lockdown mode" should have begun with stuff that's definitely safe, rather than just arbitrarily picking a smaller set of features in the hope that the smaller surface can be more easily defended.
eviks 4y ago
So how is rewriting it in a safer language not trivial in this example?
- wepple 4y ago
  Well obviously you can’t just rewrite the particular components used in this exploit chain, as attackers will hit something else next time. So you’re rewriting practically an entire OS stack from scratch, in a different language (one that is ill-suited for low-level operations needed in many parts of an OS) I’d say that’s not trivial?
  - eviks 4y ago
    Well, yeah, if you conflate rewriting a component with rewriting the whole OS, it's stops being trivial
meibo 4y ago
Well, someone or a group of people at Apple decided to give untrusted input to NSKeyedUnArchiver(a known exploitable API) in an OS-level service and it seems like no one stopped them or was there to review that code. That seems like a systemic failure to me. I'm not saying that it's impossible to check in buggy code, but it's possible to have processes to prevent this type of bug nowadays and Apple should have had these 10 years ago.

by wepple 4y ago

tialaramex 4y ago

It arguably is trivial to fix, if you prioritise fixing this. If you say OK, we want to offer safety first and features are only a nice-to-have, you can make that happen. Apple have as usual decided that nope, some of their features are a must have and if safety has to be sacrificed to get features well, sucks to be you getting exploited. Something like Swift isn't up to it. It's less easy to blow your foot off than if you wrote C++ but necessarily (as a general purpose language) you can do it. But what if we give up generality? Languages like WUFFS give up general purpose programming, solving only a narrow problem but doing so with cast iron safety because they're able to prove the system always has valid state. This is entirely appropriate when (as so often) we didn't really need generality, which means having it is a gift for bad guys. "Lockdown mode" should have begun with stuff that's definitely safe, rather than just arbitrarily picking a smaller set of features in the hope that the smaller surface can be more easily defended.

eviks 4y ago

So how is rewriting it in a safer language not trivial in this example?

wepple 4y ago
Well obviously you can’t just rewrite the particular components used in this exploit chain, as attackers will hit something else next time. So you’re rewriting practically an entire OS stack from scratch, in a different language (one that is ill-suited for low-level operations needed in many parts of an OS) I’d say that’s not trivial?
- eviks 4y ago
  Well, yeah, if you conflate rewriting a component with rewriting the whole OS, it's stops being trivial

meibo 4y ago

Well, someone or a group of people at Apple decided to give untrusted input to NSKeyedUnArchiver(a known exploitable API) in an OS-level service and it seems like no one stopped them or was there to review that code. That seems like a systemic failure to me. I'm not saying that it's impossible to check in buggy code, but it's possible to have processes to prevent this type of bug nowadays and Apple should have had these 10 years ago.