Slashdot Mirror
A Bug in FaceTime Allows One To Access Someone's iPhone Camera And Microphone Before They Answered the Call; Apple Temporarily Disables Group FaceTime Feature (thenextweb.com)
Social media sites lit up today with anxious Apple users after a strange glitch in iPhone's FaceTime app became apparent. The issue: It turns out that an iPhone user can call another iPhone user and listen in on -- and access live video feed of -- that person's conversations through the device's microphone and camera -- even if the recipient does not answer the call. In a statement, Apple said it was aware of the bug and was working to release a fix later this week. In the meanwhile, the company has disabled Group calling functionality on FaceTime app. From a report: The issue was so serious that Twitter CEO Jack Dorsey, and even Andrew Cuomo, governor of the state of New York, weighed in and urged their followers to disable FaceTime. [...] That's bad news for a company that's been vocal about privacy and customer data protection lately. The timing couldn't be worse, given that Apple is set to host its earnings call for the October-December quarter of 2018 in just a matter of hours.
The public release wasn't supposed to be compiled with CIA_FBI_NSA=TRUE
You can't fight in here - this is the war room!
There is a typo in the headline. It should read: "A Feature in FaceTime Allows One To Access Someone's iPhone Camera And Microphone"
Programmers who are accustomed to desktop applications, where there is one user, are in the habit of making things work. You click the button, it does the thing. Somebody calls someone else, they can see and hear each other.
Many of the "omg how stupid can you be?!" bugs are of the "make sure it does NOT work when it's not supposed to" variety. Once you connect an application to the internet, you have to think in terms of when things should NOT happen and test for that. Programmers who learned writing Windows desktop apps don't think in that frame of mind.
For decades one of the most popular sayings in programming was "garbage in, garbage out". That's no longer an acceptable way of thinking. That garbage that comes out, random bytes from RAM, can include your private key. Once your application is on the internet, it has to be "garbage is the default thing I'm expecting, and leads to DENIED out. Only if input exactly matches the specification will you get anything out". It's a different way of thinking.
Likely the app makes all the video and audio connections first, then rings the person if all the connections were successful. This way as soon as you answer you'll get the feeds instead of having to wait a few seconds for all the data to be sent. It sounds like a reasonable design choice, if you ignore the security and data billing concerns, which apparently they did. What a great way to waste someone's data. Constantly call them on FaceTime when you know they won't answer. I bet Apple has made more of these "UX above all else" decisions.
I'm now glad I keep my cameras covered. I don't know why phone cases don't include a manual shutter, even if it's just a silicone flap.
What is your bug-free development methodology?
As I understand it, it works like this: You call someone you want to snoop on. Then, when they don't answer, you make it a group call by saying "add member" and then add yourself. (Why are you allowed to do this? I don't know.) At this point it switches to "group" mode and now the other person is suddenly in the group call, transmitting video and audio, without ever having picked up. Presumably it would also work if you added someone else to make it a group call, but the demo I saw just added themselves.
As for how it happened, Apple missed releasing the "group FaceTime" feature when iOS 12 launched and had to delay it. Apparently they didn't delay it enough - I'm assuming they were rushing to fix whatever was holding it back, and they missed that you could force people into group calls. (I'm also unclear on if you can spy on even more people by adding them all to your new group call.)
is unfortunately long over: https://twitter.com/search?q=p... :-/ RIP
It sucks but it could be worse - you could have an Android phone that will never get any security fixes.
Err. This is an application. You understand that applications and the OS are two different things, right?
Because both revolve around photos from digital cameras. They could've called it 'T&A Time/Book' but that'd be too on-the-nose.
Corruption is convincing someone that the selfless ideal is the same as their selfish ideal.
I made a mistake a bit like this once. So to reduce latency I started recording audio before answering, and only start sending data when the user answers. I figured the best way to make sure all the code you need is loaded into ram, is to try and use it. But of course on this cheap device there's a 2KB hardware buffer you can't seem to avoid. So the person on the other end hears about 120ms of audio from before you hit the button.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
They are Agile.
It doesn't really matter if it gets patched in FaceTime. If Apple can do it in one app, deliberately or not, then someone can do it with a crafted app. It has to be assumed that anyone with an iPhone can potentially be listened to and watched at any time. Those involved in handling information of a sensitive nature need to act accordingly.
Note, this is not to say other types of phones aren't exploitable in exactly the same way. That also needs to be checked out before just switching everyone over to something else.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
People would make fun of the fact that in Star Trek TOS they had all these toggle switches, had to insert data cards, etc. Then in TNG it was all screen displays and touch panels. Buu recall multiple times in TNG the crew got locked out of the ships computer, warp coils would go crazy, and so forth. They had to crawl through Jeffries Tubes to find a junction, but again the hatch seals were all touchpad controlled. It was madness. But if you were on TOS, just flip a switch and the circuit was cut, no problem.
Phones will eventually get a physical switch to turn stuff like cameras, microphones, GPS off. Just like you can turn off your alerts. Won't happen immediately, and design aficionados will resist. But there will be some big reveal in the future about how these things are mis-used and the switches will start appearing.
IFF Facetime were a TNO platform, it would be fairly straightforward to ensure that all data that traverses from point A to point B in the software is encrypted. If it's not encrypted, nothing hits the network event loop, and unit tests make sure of it.
Facetime, of course, isn't TNO, it's "Trust Apple". They manage your keys, not you, and they are to be trusted with closed-source to not screw that up. There's no regularized enforcement of sensitive data always being encrypted (obviously).
A "paranoid" e2e-encryption programming pattern actually does help to improve development so these particular types of errors can be avoided. But to get them, Apple would have to give up some control, and users would have to take some responsibility.
That isn't Apple's market, so these slip-ups are to be expected occasionally.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)