It’s an absolutely terrible bug. These devices are so prevalent in our lives now and this bug highlights how important it is that the whole OS is locked down and secured - not just from awesome developers like us, but also from Apple’s own bugs.
[quote=422879:@Christian Schmitz]You can change the title of the thread.
I changed the title but not to “Enable It.” I’m not sure if I am enabling it again. Ever.
Here’s what I find really disturbing: this was not the result of a stupid mistake…a buffer overflow, or some obscure path to a privilege escalation of foreign code. For this to happen the code had to be engineered such that FaceTime could engage the mic and camera off a remote command or state change. There should never have been a code path for this. This mistake was made at the drawing board, not at some programmer’s workstation.
This one is very, very bad in my book because it speaks to the current quality level of senior engineers who are architecting these apps, and security staff who are supposed to be reviewing the designs. A lot of people online are dismissing it because “…no one adds their own number to a call so the GUI testers didn’t think to try it.” Not good enough. It should have been caught much, much sooner without anyone touching a GUI.
Sorry if I seem to be dramatic…I just really hate the implications of this one.
@Daniel: FaceTime is the succesor to iChat, and iChat had (like TeamViewer) the ability to remote control. I would guess that code is still in there and could have been activated and used in development, and forgotten to be deactivated so it allowed the camera to be switched on in these cases. Not good, but quality control certainly has gone down at Apple.
And yes, you do sound a tad dramatic. I sure hope you have removed all Google and Microsoft apps from your computer, otherwise youre in for a bit of a shock
@Daniel: after the “goto fail” bug a couple of years ago I have stopped believing Apple is better in programming security than their peers. With my tin-foil hat on I can see this bug (and the goto fail) as nothing but wonderful tools for three-letter-agencies and just can’t stop wondering…
I still trust them to 99% when it comes to privacy and use their products everyday.
On my primary machine? Microsoft apps are contained in VMs which are only used for work, and there are no Google binaries. I don’t use any of the VM convenience features which are intended to integrate macOS and Windows, save for one shared folder for file transfer. I do use Google for work related searches (they still have the best search results), but I only use their web apps to the extent that I’m forced to by clients.
There are no Microsoft, Google, or Facebook apps on my phone. Basically I don’t trust any of these three at all.
[quote=422896:@Mattias Sandström]after the “goto fail” bug a couple of years ago I have stopped believing Apple is better in programming security than their peers. With my tin-foil hat on I can see this bug (and the goto fail) as nothing but wonderful tools for three-letter-agencies and just can’t stop wondering…
I still trust them to 99% when it comes to privacy and use their products everyday.[/quote]
I would say macOS / iOS are better, but I don’t know how much of that is heritage (UNIX) and how much is current practice. Bugs like this FaceTime one make me think “heritage.” Then again, Apple clearly puts a lot of effort into Secure Enclave.
Unfortunately I share some of Daniels deep concern. Ive been thinking about it all day - why is there a way to engage the camera by pushing the power (sleep/wake) button? Why is that a thing?
I still trust Apple more than others, by virtue of the fact that they make their money from selling physical products, not information. Nevertheless, this and the recent Mac root password issue are deeply, deeply concerning.
We all know that today’s programming is event-driven, I don’t share the view of well laid out “code-paths” laid out here.
The power button in iOS does many crazy things, one is to silence an incoming call another is to made an emergency call if pressed five times for example.
Looking at this as a couple of events I really can see this happen:
the device receives a facetime incoming call and starts the camera (normal way - you see yourself on the screen when you pick up a facetime call)
while having an incoming call, another incoming call - the group call - arrives
user presses the power button to silence the incoming call
the event handler for the power button contains a flaw (be it malicious or not) and cannot properly tear down the two simultaneous (yet to be started) calls.
This is the problem. Apple is activating hardware without the user authenticating the incoming call for which the hardware will be used. Now when you have a flaw where the call proceeds instead of being terminated, everything is connected and transmitting data.
Any request to use a camera or mic…regardless of how it started (what event)…should pass through a piece of code that says “did the user actually authorize this?”
[quote=423051:@Daniel Taylor]This is the problem. Apple is activating hardware without the user authenticating the incoming call for which the hardware will be used. Now when you have a flaw where the call proceeds instead of being terminated, everything is connected and transmitting data.
Any request to use a camera or mic…regardless of how it started (what event)…should pass through a piece of code that says “did the user actually authorize this?”[/quote]
The tricky part there is you should definitely see yourself before you pick up. The work safe explanation being “in case you have something on your face.” The issue is that the data was being transmitted when the user expected it not to be.
It’s the way to think about it if you want a secure system.
The alternative explanations do no such thing. “We never tried that mix of events” is the same as “no one does that so the GUI tester didn’t try it.” They are an admission that no one traced out the possible paths and states of the subsystem, therefore no one could have reasonably signed off on it as secure.
I don’t know what to say to that because most people would want it that way, but my thought is the risks are too great. I would prefer two step authentication (i.e. do X to see face preview; do Y to answer the call). Providing a ‘code path’ (why is that term so daunting to some?) to activate the camera in response to a network event is half the battle of getting camera data back over the network to someone who wants it, whether or not you want them to have it.
It is what it is. Apple will fix it. I just hope the fix involves a review of the code which manages the mic and camera.
For a dinosaur such as myself I interpret this as something like C’s main() function where the lines of code are executed one by one in an orderly fashion. I normally use the term “logic flow” to describe what’s going on inside the application.
I cannot even begin to image all the events and callbacks flying around in the phone when a facetime call is being setup. All those asynchronous calls to sub-systems (camera, call logic, authentication etc. etc) that requires all handlers to be in sync. All the best laid out intentions and promises (your “code paths”?) break down because the user tosses a wrench into the machinery by pressing the power button.