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

If I were Apple, I would be implementing a server side migration right now:

- if someone adds their own email or phone number again to a group chat, immediately terminate the call

As far as I know, this would mitigate the vulnerability.

Alternatively, disable Group FaceTime calls altogether.



It might trigger the bug to just invite any additional participant (say, a second phone the attacker possesses), in which case blocking only inviting oneself is not sufficient.

My theory is that the server routes messages to everyone who has been invited to the call, even if they have not accepted it. One message might be "participant left," in which case if you are the last one, the call ends.

Another would be "participant joined." The bug would center around the fact that the logic for handling a "participant joined" message does not check if the call has been accepted and makes an unexpected transition to a state that it should not be in.

The "participant joined" code likely handles the case that the new participant was already present on the call. Why? Apple wants to support seamlessly transitioning your call from one device to another. That's why blocking might not be so straightforward from the server side.


> Alternatively, disable Group FaceTime calls altogether.

Apple has just done this.


I'm pretty sure there are a lot of Apple engineers evaluating and testing fixes (including this one) as we speak.




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

Search: