While iOS seems to pioneer every mitigation technique ever described in the literature, they also shipped ancient versions of C image parsing libs (OpenEXR), have an endless stream of remote code execution vulnerabilities from their peculiar serialization schemes and all the other issues you would expect from the use of native ObjC.
Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace.
The issue doesn’t seem to be ObjC per se. It’s the use of a facility that tries to transparently serialize an object in any rich language. Python pickle has the same issue, although it’s arguably worse in Python.
The solution is to abandon the whole approach — these systems should not be used across trust boundaries. Apple should create iMessage v2 using a real serialization system (protobuf, JSON, XML, ASN.1, etc) and deprecate
the old scheme. It’s surely possibly to write a safe but non-extensible deserializer for the old protocol if compatibility is needed.
>Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace.
As a practical matter, doesn't this mean if I'm confident in my ability to avoid phishing messages, iOS is better?
Anything that "roots" a phone can also run roughshod, turn on my mic, grab signal messages stored locally, etc, correct?
What I'm getting at is a phone in a walled garden + a laptop that's open source might be the best way to get the security of the walled garden and the utility of open source.
I'd argue it is the opposite. The people that want to grab your Signal or WhatsApp messages can often do so by simply sending your some picture or specially crafted message; it's only the people that want to run their own software that need to break all the kernel defenses and 'root' the device.
No, they are entirely different features. Pointer authentication is largely a control-flow integrity feature. Hardware memory tagging attempts to prevents arbitrary overwrites/memory corruption, even to data. There are dozens of other features that prevent memory corruption and it's not really "playing word games" to distinguish between them.
I assume you're not talking about this: https://developer.apple.com/documentation/security/hardened_...? And to your other point: the difference between these things do matter because they have entirely different semantics and protect against different things, although the overarching goal of preventing undesired operation is the same. Taking the metaphor one level up to apply to computer science rather than security, this is like saying that the borrow checker and asserts are both the same from a certain point of view because they both help prevent bugs. Which is true, of course, but when you're talking about a programming language's safety features saying something like "C can prevent use-after-free because of its borrow checker" is not correct nor can you make it relevant by saying something like "yeah but C has asserts and they also help prevent bugs so from my point of view I think you're being pedantic".
Thing is, every time we discuss this it ends up following the same path.
I see these iOS features as a mechanism to improve C safety on iOS, while you don't.
We would be better if Apple would just reboot the whole stack in Swift, but that will take years, if ever, so from a security advocate point of view, I see that better as what PCs offer nowadays, specially after the misstep that MPX ended up being.
I have nothing against improving the safety of languages that have historically had issues in this regard; in fact, I have actually called out companies for turning off mitigations: https://news.ycombinator.com/item?id=23448161. The point I'm making here is that the things you mentioned are different things and they protect against different types of attacks.
Just for completeness, BTW, iOS devices after iPhone XS ship with PAC, which is part of ARM-v8.3; memory tagging is an extension of ARM-v8.5. Rumors point to the A14 chip supporting that but there's no word on whether Apple will support the extension.
iOS also sometimes creates their own mitigation techniques. Sometimes these are quite strong but often they are…not really mitigating anything; in rare cases they make the situation worse. Shipping every mitigation under the sun is not necessary a good idea.
Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace.