3 ms·

A third party client in iMessage allows for spam attacks, and (worse) malicious payload attacks. It’s very much in the interests of security that Apple fence th

by 7e 3y ago

A third party client in iMessage allows for spam attacks, and (worse) malicious payload attacks. It’s very much in the interests of security that Apple fence them out.

danShumway 3y ago
I don't think it's at all clear that the approach you describe is working: https://www.wired.com/story/imessage-interactionless-hacks-google-project-zero/ https://www.wired.com/story/imessage-interactionless-hacks-g... (2019), https://www.forbes.com/sites/daveywinder/2023/06/02/warning-issued-for-iphone-users-as-ongoing-imessage-0-click-attack-revealed/ https://www.forbes.com/sites/daveywinder/2023/06/02/warning-... (2023) Of course, this is a hard problem. I'm not saying Apple is bad at security, many good messaging platforms run into these kinds of problems. But the way you fix these problems (and the way Apple in fact did fix the bugs above) was through patching their own software, not by trying to control what attackers can send. If security researches can send a malicious payload attack that compromises iMessage, the solution is not to make sure they can't send that payload (which would be impossible to guarantee anyway), the solution is to patch iMessage to no longer be vulnerable to that payload attack. One hopes that the only thing preventing your iMessage client from being compromised is not whether or not the attacker has a spare $1,000 lying around.
- api 3y ago
  The longer term solution is to stop using memory unsafe languages.
  - danShumway 3y ago
    Regardless, when a buffer overflow happens, it's not reasonable to say, "well, we'll just make sure nobody sends us badly formatted or maliciously formatted data. As long as only iPhone users can send us data then we can trust it." The actual solution is to make the client/server not be vulnerable to malicious payloads that would cause a buffer overflow. Whether you do that by patching bugs individually or switching to a memory safe language, or whatever strategy is used -- "don't send our messaging platform bad data" isn't a security fix.
pcwalton 3y ago
On macOS iMessage is scriptable in various ways (both officially supported and unsupported), so the security argument doesn't hold water to me. It's a business decision.

by 7e 3y ago

A third party client in iMessage allows for spam attacks, and (worse) malicious payload attacks. It’s very much in the interests of security that Apple fence them out.

danShumway 3y ago

I don't think it's at all clear that the approach you describe is working: https://www.wired.com/story/imessage-interactionless-hacks-google-project-zero/ https://www.wired.com/story/imessage-interactionless-hacks-g... (2019), https://www.forbes.com/sites/daveywinder/2023/06/02/warning-issued-for-iphone-users-as-ongoing-imessage-0-click-attack-revealed/ https://www.forbes.com/sites/daveywinder/2023/06/02/warning-... (2023) Of course, this is a hard problem. I'm not saying Apple is bad at security, many good messaging platforms run into these kinds of problems. But the way you fix these problems (and the way Apple in fact did fix the bugs above) was through patching their own software, not by trying to control what attackers can send. If security researches can send a malicious payload attack that compromises iMessage, the solution is not to make sure they can't send that payload (which would be impossible to guarantee anyway), the solution is to patch iMessage to no longer be vulnerable to that payload attack. One hopes that the only thing preventing your iMessage client from being compromised is not whether or not the attacker has a spare $1,000 lying around.

api 3y ago
The longer term solution is to stop using memory unsafe languages.
- danShumway 3y ago
  Regardless, when a buffer overflow happens, it's not reasonable to say, "well, we'll just make sure nobody sends us badly formatted or maliciously formatted data. As long as only iPhone users can send us data then we can trust it." The actual solution is to make the client/server not be vulnerable to malicious payloads that would cause a buffer overflow. Whether you do that by patching bugs individually or switching to a memory safe language, or whatever strategy is used -- "don't send our messaging platform bad data" isn't a security fix.

pcwalton 3y ago

On macOS iMessage is scriptable in various ways (both officially supported and unsupported), so the security argument doesn't hold water to me. It's a business decision.