Slashdot Mirror
Google's 'Project Zero' Hid A Major Vulnerability in Apple's OS and iOS Cores (thestack.com)
In June Google's task-force against zero day exploits "identified a coding exploit in the underlying kernel of Apple's OSX and it's mobile operating system iOS, which could allow for root-level escalation of privileges for an attacker in a non-updated version of the OS," according to The Stack.
An anonymous reader writes that Google "initially refused Apple's request for sixty days' grace, but eventually settled on September 21st for disclosure. But when Apple's last-minute September fix turned out to be ineffective, Project Zero agreed to keep quiet, eventually granting Apple nearly five months of silence about the task_t bug -- which has now been fixed in the latest updates to Mac OS and iOS." The fix was released Monday, the Stack reports: Since the task_t bug allows the user to gain any entitlements they may want, it could also nullify kernel code signing, which would allow unauthorized programs to run with elevated privileges on a Mac system. Any current OSX or iOS user who has applied the latest system updates is not susceptible to the task_t vulnerability.
An anonymous reader writes that Google "initially refused Apple's request for sixty days' grace, but eventually settled on September 21st for disclosure. But when Apple's last-minute September fix turned out to be ineffective, Project Zero agreed to keep quiet, eventually granting Apple nearly five months of silence about the task_t bug -- which has now been fixed in the latest updates to Mac OS and iOS." The fix was released Monday, the Stack reports: Since the task_t bug allows the user to gain any entitlements they may want, it could also nullify kernel code signing, which would allow unauthorized programs to run with elevated privileges on a Mac system. Any current OSX or iOS user who has applied the latest system updates is not susceptible to the task_t vulnerability.
Was this a unix-linux level bug that would affect all systems built on top or was this an OS X/iOS-induced bug from layers that sit on top of the kernel? Was BSD-derived systems similarly affected, or Android systems?
Is there a counterpart in the wild in Linux-land?
It is frustrating when you read the title for a thread and get one idea of what happened, but when you read the details it is very different. Simply saying that you hid something is ambiguous and can lead others to think it was nefarious. In this case it was a mutual understanding. Slashdot can do better than this.
Isn't the point of eventual disclosure to force coders/companies not to ignore bugs?
Yes, Google found a bug. But Apple didn't ignore it - their initial patch just wasn't effective. They were obviously actively working to solve the problem... so why should Google have released the exploit?
#DeleteChrome
It's been a long time waiting on a jailbreak since they got so valuable. I'd do the same thing "Hmmmm... release this as a jailbreak, or sell it for a million bucks..."
This looks easy enough to get working and is current up to 10.0.2 or whatever the latest was.
Cwm, fjord-bank glyphs vext quiz
Yea sure, Slashdot has editors and our elections are not rigged. But if there were really editors, how could you make sense of a September 21st for disclosure and a claim that Project Zero agreed to keep quiet, eventually granting Apple nearly five months of silence? This would only be explained if editors couldn't do simple math or if they didn't know how long a week and a month is.
I'm an American. I love this country and the freedoms that we used to have.
Did you read the summary? Apple's initial fix didn't work well, so Google responsibily allowed Apple more time to fix the vulnerability.
That is speculation. Apple was actively working on it and I rather the fix not cause more vulnerabilities simply because someone was impatient.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Sued for what? There's no legal remedy for somebody making truthful statements. It just happens to be common industry practice to give some time for a patch to be made while making full public disclosure an ultimatum for somebody not releasing timely patches.
A lot of armchair-lawyer-Microsoft-fanboys like to fault Google for disclosing a windows bug after such a notice just because Microsoft themselves complained about it, but Google didn't break any laws, let alone any industry norms at the time, so go put your head back in the Azure where it belongs.
Using the words "hid a major vulnerability" is misleading. It implies Google infiltrated Apple source code to implant an exploit. Google didn't hide shit. They found the exploit, informed Apple, and kept quiet about it for the safety of the users.
That the plaintiff himself made possible by his very own neglect. That's like suing someone for sending pictures of you cheating on your wife to her and you want to get compensation for the divorce.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Did you read the summary? Apple's initial fix didn't work well, so Google responsibily allowed Apple more time to fix the vulnerability.
Yes I did. And it was about allowing them 60 days which since the fix didn't even solved the problem completely become 5 months.
It likely didn't have to take 60 days or 5 months if that wasn't the time they had available to them but since it was that's how long it took. It's like there in Sweden where what the municipality get for each refugee "child" is $77 000 / year and hence that's what their solutions end up costing (or more since so many arrived), if they had only been offered $20 000 / year then they would have had to go with cheaper solutions.
Of course it could be fixed faster than within 5 months and Apple likely would have had to do it very quickly if the exploit was known in the public.
That is speculation. Apple was actively working on it and I rather the fix not cause more vulnerabilities simply because someone was impatient.
True. But it being speculation doesn't make it incorrect. With more vulnerabilities do you mean the implementation of the fix or by just being known? Being known doesn't create a new vulnerability but it may jeopardize more units and users but as said at-least then they can be aware of it whereas not making them aware with of it and taking your time to fix it may also do that and no-one very few know about the risk you're putting them through.
Yet the vulnerability was fixed and it allowed Apple to push out an update.
Or the more likely scenario would be that the same number of engineers will still work on the vulnerability, except now an exploit was disclosed putting people at risk.
Whenever a change is made to the software, especially something as complicated as an OS, you need to allow time for regression testing to make sure the modification doesn't introduce a different vulnerability elsewhere.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Because the summary and both articles are ambiguous, I was confused what was meant by "latest system updates." For anyone else wondering, this vulnerability was patched in Yosemite, El Capitan, and Sierra -- not just Sierra. See under "System Boot" heading here: https://support.apple.com/en-us/HT207275.
Keep your eyes to the sky.
Ah yes, the old "you can speed up anything by throwing more people at it," argument.
Have you ever worked in any professional engineering role? I suspect not, since you seem completely unaware of the need to understand the issue, develop a reasonable solution, implement that solution, test the solution, and then roll it out to the world. All of these take a commodity that's known as "time" to do, and honestly, for a major security bug that requires extensive rework, 2-5 months is completely understandable and reasonable.
Right, and 9 women could pool their efforts to have a baby, and deliver a single baby in 1 month, if they'd just work smarter. And Elon Musk could totally come up with a faster way to get people to Mars if the public demanded it. There are no irreducible constraints that can't be fixed by the public demanding it. It's the reason we all have free healthcare, incredible political candidates, and peace in the Middle East!
You sound like a retard. Have you bumped your head recently? Perhaps you should get an MRI to make sure you haven't had a stroke.
Using the words "hid a major vulnerability" is misleading. It implies Google infiltrated Apple source code to implant an exploit. Google didn't hide shit. They found the exploit, informed Apple, and kept quiet about it for the safety of the users.
I wish you had posted this before I blew all of my mod points.
I can name that mitigation in a one-step operation.
1. Throw you iPhone into a wood chipper. Done!
You are welcome on my lawn.
Whenever a change is made to the software, especially something as complicated as an OS, you need to allow time for regression testing to make sure the modification doesn't introduce a different vulnerability elsewhere.
Whenever you have a vulnerability as serious as this one, you better make sure that those regression tests go quickly.....faster than five months.
Not that I care, iOS should be liberated from its walled garden, and privilege escalation exploits are the way to do that.
Irresponsible disclosure is responsible
Or the more likely scenario would be that the same number of engineers will still work on the vulnerability, except now an exploit was disclosed putting people at risk.
Has there been a case where that have actually happened? In that a known full access exploit in Microsoft or Apple products has been allowed to take five months to fix? How much negative publicity wouldn't Apple had gotten if it really took them five months to fix it with lots of exploited Apple devices all over the world? Samsung Note 7 would quickly had moved back to device issue #2?
Whenever a change is made to the software, especially something as complicated as an OS, you need to allow time for regression testing to make sure the modification doesn't introduce a different vulnerability elsewhere.
I know nothing about the vulnerability and where it existed so I can't comment on that.
You are thinking of libel. Disclosing details of a vulnerability that can be used maliciously is a gray area. It's been covered by EFF and a blackhat presentation, and it's not as cut-and-dry as you asserted.
How is it a legal gray area? Who has been successfully prosecuted for it?
100% this. The threat to release an exploit is to get the vendor moving towards a fix. When apple did actually work on a fix, Google did the right thing and kept it mum. If it had been caught in the wild as a 0-day then it would have been responsible to release, but not before.
Silence is a state of mime.
AC if a big brand can find an issue, so can its staff. So can other nations security experts. So can cults, faith groups, criminals and ex gov/mil security experts.
If data is released when found, the holes can be patched quickly and a world of really great security researchers can help comment on the issue and help.
Why wait a longer time for an in house fix with even the slightest the risk of an issue been in use in the wild for the same time.
Report on detection, get the community to fix. Days of waiting just becomes days of risk.
The more experts that see interesting issues early and often, the better.
Domestic spying is now "Benign Information Gathering"
Yes because if this had happen with Android, Google would have quickly issued a patch for all phones introduced since 2012 and all of the affected Android devices could have downloaded the patch immediately without having to wait on the OEMs and the carriers....
Now back to the real world....
Or would it?
This is a kernel level bug. Kernel bugs are extremely tricky and from the looks of it, it's a core kernel issue. This level of code is at the core - make a mistake here and the kernel stops working.
Hell, at this level of code, few people actually even know how it works. So you can't even throw more bodies at it, because those bodies just don't exist, and it will take a month to bring them up to speed. (Same thing in Linux - at this low level few people, including Linux, actually know how it works).
Oh yeah, you also have to test it thoroughly because a change at this level can break userspace very easily. And trigger a bunch of follow on bugs because things have changed. Which will usually exhibit themselves as oddball hangs, stutters, or crashes.
It's not just a kernel bug, it's a bug in an interface between the kernel and userspace programs that have intimate knowledge of the kernel. Fixing it in such a way that you don't break existing non-malicious applications is probably much harder than fixing a bug that is entirely in the kernel.
I am TheRaven on Soylent News
My iPhone is too old to support the vulnerability, I'm good!
Website Just Down For Me? Find out
Ah where are my mod points when I really want them?
How many non-tethered jsilbreaks have been available for the iPhone recently? The reason that the jailbreak be "non tethered" is important is because a tethered jailbreak implies physical access to the phone and the ability to unlock it.
A tethered jailbreak isn't a major security risk.
that pretty much sucks to keep it hidden for 5 months.
all the while releasing a windows vulnerability before a patch is out.
sounds like double standards to me.
On a long enough timeline, the survival rate for everyone drops to zero.