91–100 of 458 posts
Earlier quoted context omitted.
This would actually be a fun interview question - how to emergency patch 1B+ globally distributed mobile devices. I would say at least several days for the obvious QA which needs to be done.
>I would say at least several days for the obvious QA which needs to be done. And you would unfortunately, not get the job.
This is due to the very poor QA efforts Apple has, coupled with junior developers who lack a security-aware mindset. This is, sadly, the case with most companies these days. Zero secure coding training, zero push for security reviews, zero push for security QA, zero accountability.
What makes you think this?
I'm always curious how a bug like this ships. I mean QA & Testing should catch it, sure. But even before then. Some engineer wrote code for FaceTime that has it open the microphone before the call is accepted. And transmit the audio over the network before the call is accepted. Who did that? And why? I'm not suggesting malice but I do wonder at the lack of defensive programming.
Earlier quoted context omitted.
The team might be able to fix it today, but the fix needs to go through testing and then be built alongside the rest of iOS (a multi-hour process). I wouldn’t be surprised if this takes two or three days to roll out.
They obviously didn't test it the first time out. Why do they need to test it this time?
Not for long. Will be patched in hours, I bet.
Earlier quoted context omitted.
> Is there any historical evidence that high-severity bugs in iPhones (or really any mobile phone) are reputationally damaging, sufficiently that Apple would worry about the impact of this bug? I'm sure Apple "worries" about any bug and its potential impact on its reputation, particularly in the area of privacy, where it has a leg up on Android at least in perception. That said, what historical bug is up to this one…
https://www.zdnet.com/article/ios-mac-flaw-exposes-your-pass... Where sending somebody a .tiff file via iMessage, web page, or email would give the attacker RCE on the device.
I also don't think it had the impact you're suggesting, nor would it be as immediately palatable as a privacy issue to the layperson.
That's a pretty huge flaw. Millions if not billions of people can suddenly remotely spy on almost any other ios or mac anywhere in the world, just by knowing their email address or phone number? Perhaps Apple should simply pull the plug on the facetime servers for now.
Unless Apple decides they face significant legal exposure over the bug somehow I don't see them doing that. It would attract so much more attention that it would almost certainly not be worth it economically. I wonder if they (executives? engineers? the company itself?) could be charged with aiding and abetting wiretapping or something now that they know it's happening and are letting their servers keep doing it.
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.
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.
I'm always curious how a bug like this ships. I mean QA & Testing should catch it, sure. But even before then. Some engineer wrote code for FaceTime that has it open the microphone before the call is accepted. And transmit the audio over the network before the call is accepted. Who did that? And why? I'm not suggesting malice but I do wonder at the lack of defensive programming.
I just called my friend who was already on a call talking to his brother. He could hear me and his brother but his brother and I couldn't hear each other. I was also able to call him, have him hang up and then see his video and hear his audio. He couldn't hear me, but I could hear and see everything. I'm turning my phone off tonight!