Slashdot Mirror
Apple Says It Will Fix The FaceTime Bug That Allows You To Access Someone's iPhone Camera And Microphone Before They Pick Up (buzzfeednews.com)
Apple said Friday morning that it had a fix for a bug discovered in Apple's video and audio chat service FaceTime this week, which had allowed callers to access the microphone and front-facing video camera of the person they were calling, even if that person hadn't picked up. The security issue is fixed on its servers, the company said, but the iPhone software update to re-enable the feature for users won't be rolled out until next week. From a report: "We have fixed the Group FaceTime security bug on Apple's servers and we will issue a software update to re-enable the feature for users next week," Apple said in an emailed statement to BuzzFeed News. "We thank the Thompson family for reporting the bug. We sincerely apologize to our customers who were affected and all who were concerned about this security issue. We appreciate everyone's patience as we complete this process."
Thanks. It is nice to get these small issues fixed.
-SuperKendall
Sure it is a big deal security lapse from Apple. So the received/found the problem, analysis the scope of it, stopped the service, sent out communication about the problem. Now they are applying a fix.
It seems like a responsible course of action.
I am sure people who hate Apple, because they were beaten up by a hipster a few years ago, will still fault Apple, and make them seem like a pile of idiots who cannot code themselves out of a paper bag. But these things happen, I am actually surprised it doesn't happen more often.
I am sure all you programmers out there who are smug that their code never got hacked. But is it really skill, or just being lucky, or your program isn't just that popular enough. It can often just be a bad day where your code has a security flaw in it, and coded so it would be difficult for the QC to find it. However within weeks of it being public it was was found as a problem. I myself never had my coded hacked, however this isn't a reason to pat myself on the back, or be smug and judgemental, as I have fixed things in my own code that could had been bad if I didn't catch it. And I never know what else I may have open.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You're under the false impression that the user owns the phone; the actual owner (Apple) can choose to do with it as it wants, including letting their servers decide when your sensors are active.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
You know it's bad when a 14 year old with no coding experience discovers a major security flaw bug a multi billion dollar tech company couldn't find, emails it to Apple tech support, then nothing happens for a week till it's headline news. People aren't going to keep buying into this North Korean business model if the prices continue to rise faster than hardware quality and the redeeming quality of security is reduced to being seen as far less secure.
Well, the application already has permission to activate the camera and microphone, otherwise the "server" wouldn't have the ability to cause them to be activated.
So this isn't the fault of the phone or the server. Nor is it the fault of Apple's security model. It's the fault of the face time app. The face time app should never enable the microphone or camera until the user answers the call, regardless of what the server does.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Oh, how the mighty have fallen.
I don't know... I get most of my tech news from websites built on the readership of angry vegan teenage lesbians.
"That's the way to do it" - Punch
You're under the false impression that the user owns the phone; the actual owner (Apple) can choose to do with it as it wants, including letting their servers decide when your sensors are active.
They do own the phone. The hardware is theirs and Apple cannot get it back. The SERVICES and software the phone uses are not owned by the user. They license or subscribe to those and whatever terms come with them. Yes, these are necessary for the device to be useful but that is a separate discussion from who owns the hardware. This is yet another example of why Apple is a software company, not a hardware company. The hardware is just the pretty box through which they sell their software and services.
"We thank the Thompson family for reporting the bug.
From all the billions [of dollars] in profit Apple makes, I wonder whether this family will collect. Anyone know?
That mere "thank you" message from Apple is anemic in my opinion.
It's a predictive video and audio caching algorithm. iOS 13 is rumored to add a feature that will pre-shatter your screen when the accelerometer detects the phone is falling.
I don't like to play entitled, but this sort of bug is the sort of bug that you stay up all night to fix immediately.
Liberty - Security - Laziness - Pick any two.
Both candidates knew the rules of the games before they played, so fair is fair and like it or not,Trump won fairly.
What? No he didn't. Even if Trump didn't know about it (which is unlikely, but let's posit) his campaign definitely colluded with Russia to manipulate the election illegally. There's nothing fair about that.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
So this isn't the fault of the phone or the server. Nor is it the fault of Apple's security model. It's the fault of the face time app. The face time app should never enable the microphone or camera until the user answers the call, regardless of what the server does.
Chances are that this is something silly, like incorrectly assuming that a group connection request is a new person being added by someone in the group already, who therefore should be connected immediately, while failing to check if the group is actually connected yet.
Still, this makes me seriously question whether Apple’s aggressive push to hire so many junior employees straight out of college is having a major negative impact on their code quality. After all, this required two different teams to write code that fails to check state properly. The client should have refused to connect the stream before the call was established, and the server should have refused to ask for one. Two *different* teams at Apple failed to care enough about customer privacy to make sure that FaceTime couldn’t become a tool for spying on users.
This doesn’t point to a minor problem, but rather, suggests a fairly fundamental problem in the protocol (the server not knowing the state of the connection). Of course, there’s no way to know for sure, because Apple never published the FaceTime communication protocol like they said they were going to. Odds are, this flaw would have been prevented had they put security above their proprietary nature and published it as an open specification during the product development cycle. And this, boys and girls, is why proprietary protocols are bad.
Either way, this is one seriously bad mistake that could only happen if a *lot* of employees were *all* grossly negligent about security and failed to understand basic threat modeling. So this sounds to me like a major systemic problem that needs to be fixed from the top down with real leadership. Mr. Cook, it’s time to step up.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The report on the "fix" reveals a fundamental design flaw. They say they fixed the issue ON THE SERVER.
That means the CLIENT on the phone is expected by design to start sending audio and video as soon as a call comes in (before you answer).
If it was anything like properly designed, the client would never under any circumstances transmit from the mic or the camera unless and until the called party chooses to answer.
So a patch for iOS7 for my iPhone 4 will be available soon?
#DeleteFacebook
is it really skill, or just being lucky, or your program isn't just that popular enough. It can often just be a bad day where your code has a security flaw in it https://audacity.onl/ https://findmyiphone.onl/ https://origin.onl/
As complex as these applications are and with as many hands involved in development of them, I find it encouraging that they have so few serious bugs..
Where I get that such things shouldn't make it into prime time, the reality is that any large complex development project with as many moving parts as this application has, it's *really* hard to always catch all these things. Hiring inexperienced engineers may be an issue, but even hiring developers with 30 years of development experience in untra-secure environments doesn't fix the problems either. Sometimes, stuff happens, folks make mistakes, nobody thinks of the unique set of events or development of new features isn't fully integrated into the application's design in security. Humans make mistakes.
I'm not giving Apple a pass, I'm just saying they are obviously reacting correctly and you can bet they will revisit their security testing processes to find and correct the process that lets this mistake into the production article.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
I don't. I find it suspicious. When something this serious and easily discoverable (not by hackers, but by end users) makes it out into a released product, I assume that it is just the tip of the iceberg. How many more serious security problems just haven't been discovered yet? And how many of them have been found and are being secretly exploited by groups who don't have any motivation to disclose them?
The first rule of secure programming is to assume that the client is hostile and is trying to access resources that they are not authorized to access. I can't even begin to imagine how something like this could possibly get into production, because it should have been stopped at least three times, and arguably four:
Those are three very different bugs at three very different levels of the system — a client UI design bug, a client state machine design bug, and a server failing to check state properly before passing on a request from a hostile client to another client. This wasn't just a failure to think about the edge cases. Rather, this should only be possible if you almost completely fail to design the app or the server at all. And that's the best case scenario. There might be even deeper design flaws, like using the same message to trigger two different client behaviors. We can't know for sure, because the protocol is unpublished.
IMO, there are really only two ways to explain such a comedy of errors: either the programmers who designed this were too inexperienced to be trusted to design a protocol by themselves or the product was rushed to market, resulting in inadequate time for proper design and testing. And the fact that group FaceTime support was almost two months late further supports that assertion. Either way, the root cause is bad management, and the problem needs to be fixed from the top down (read "by replacing people from the top down").
Well, no, actually there is a third possible explanation. Given the history of various spy agencies attempting to inject remote monitor
Check out my sci-fi/humor trilogy at PatriotsBooks.