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.

Comments

How is this a problem, exactly?

[93 Escort Wagon]

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?

Re:Where exactly was the bug...

[Shimbo]

It was a performance hack for a microkernel system, so no. Apple had to do some extensive reworking to fix it, so it seems sensible to me to cut them some slack in this case.

Phrasing! Click bait headline.

[Anonymous Coward]

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.

Fixed in 10.10.5, 10.11.6, 10.12 -- NOT just 10.12

[boarder8925]

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.

Re:Because it took five months to fix?

[Anonymous Coward]

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.

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.

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.

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!

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

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.

Re:Because it took five months to fix?

[aliquis]

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.

Re:Phrasing! Click bait headline.

[wbr1]

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.

Re:Because it took five months to fix?

[Karlt1]

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....

Re:Because it took five months to fix?

[tlhIngan]

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.

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.

Re:Because it took five months to fix?

[TheRaven64]

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.

safe

[slazzy]

My iPhone is too old to support the vulnerability, I'm good!