Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple's OS X 10.10.2 to Fix Security Vulnerabilities Exposed by Google's Project Zero
- Thread starter MacRumors
- Start date
- Sort by reaction score
Right, the fact that they were beta testing this release for weeks previously, means they just popped that new code in (for this bug) and then released it without testing it... just because Google released the exploit... Totally "believable"... That's how software development really work... In bizarro world.
Since Apple is still doing security updates for Mountain Lion and Mavericks, one can be pretty sure that they will.
They did need to patch IOS, just checked the release notes for IOS 6.1.6 and IOS 7.0.6, they fixed the heartbleed SSL bug. Apple did use OpenSSL code.
the patch was for the triple handshake bug...totally different and nowhere near as devastating as heartbleed.
This is actually a good point. We know the largest buyer of private exploits is the NSA and that Microsoft would leave vulnerabilities un-patched when the NSA requested it.
I don't think Apple would do that, but its probably better to publicly push companies to close the holes.
It isn't so much a question of demands as working together to find a pragmatic solution to the problem.
I think it would be unreasonable to allow this period to extend forever, but if we are talking about weeks or days, I don't see what Google would lose, and even less how it would corrupt the entire project.
Unfixed issues exist on Google's products as well, why don't they apply their 90 day limit there?
http://www.engadget.com/2015/01/14/google-security-bug-billion-android-phones/
Look at all these folks getting upset that Google has done this. Google is doing these companies a great service and helping the Apple and Windows fanbases in the process.
Well, I guess I'll just sell my shares of the company to my partners and head home to retire then... (sic)
Continue thinking whatever... I'll continue living in the real world.
----------
When they start caring as much about their own software as they care for other people's software and not dogmatically releasing things like this a few days before their patched, well then we will thank them. For now... I don't think so.
Informing them of security hole is fine, this publicing exposing the flaw is the dirty part in my eyes.
The only outcome is that public perception of the OSX and Apple will be negatively affected. Also this will encourage other 'hacker' type to look for more faults.
While it is not illegal, it is definately feels vindictive.
Oh, right confused the bugs, this was the Gotofail bug. They happened around the same time (1 month in between)
Your tone in all posts in this topic is Google bad, Apple is OK.
Why not focus on helping Apple fix their bugs instead of derailing the topic to Google when the topic IS, APPLE HAS SECRUITY FLAWS THAT WERE NOT PATCHED IN 90 DAYS AND ARE STILL EXPOSED!
*I assume it must be very slow work year for SW development considering the ample time you spend at MR to defend Apple at any cost.
Last edited:
To those complaining about the disclosure:
There are three basic schools of thought as far as public disclosure of security bugs:
1) Immediate Disclosure - Public disclosure of the bug and sample exploit/test code as soon as the sample can be created and verified.
2) 'Responsible' Disclosure - As above, but provide a fixed deadline for public disclosure. The fixed deadline provides an incentive for the company to get to work on fixing the bug.
3) Delayed Disclosure - Inform the company responsible for the code immediately (as defined above), but only disclose the bug to the public once the bug is fixed.
4) Private Disclosure - As above, but *never* publicly disclose the bug.
We had more than a decade of security researchers 'standardizing' on options 3 & 4. During that period, it wasn't uncommon for bugs to be reported to the owner of the code, and have them go unfixed for *years*. In the mean time, they were *often* exploited in the wild, because 'black hats' *also* found the bugs.
For a while, option 1 looked to be gaining more ground (and a few groups *do* still subscribe to it), but it opens up the window for a serious bug to be widely exploited. At the same time, it minimizes the window for a serious bug to be exploited without *any* mitigating factors being added.
Option 2 is a careful balancing act between minimizing guaranteed exposure of the bug to 'black hats', while making the information about the bug available to people *running* the systems so that they can deploy some form of mitigating security.
There are three basic schools of thought as far as public disclosure of security bugs:
1) Immediate Disclosure - Public disclosure of the bug and sample exploit/test code as soon as the sample can be created and verified.
2) 'Responsible' Disclosure - As above, but provide a fixed deadline for public disclosure. The fixed deadline provides an incentive for the company to get to work on fixing the bug.
3) Delayed Disclosure - Inform the company responsible for the code immediately (as defined above), but only disclose the bug to the public once the bug is fixed.
4) Private Disclosure - As above, but *never* publicly disclose the bug.
We had more than a decade of security researchers 'standardizing' on options 3 & 4. During that period, it wasn't uncommon for bugs to be reported to the owner of the code, and have them go unfixed for *years*. In the mean time, they were *often* exploited in the wild, because 'black hats' *also* found the bugs.
For a while, option 1 looked to be gaining more ground (and a few groups *do* still subscribe to it), but it opens up the window for a serious bug to be widely exploited. At the same time, it minimizes the window for a serious bug to be exploited without *any* mitigating factors being added.
Option 2 is a careful balancing act between minimizing guaranteed exposure of the bug to 'black hats', while making the information about the bug available to people *running* the systems so that they can deploy some form of mitigating security.
I've seen you complain about Google but offer no commentary about the vulnerabilities. Do you think it would have been better for Google to report the vulnerabilities to CERT or IETF? I ask because Google gives companies 2X the window of CERT (45 days) and 3X the window of IETF (30 days). Honest question: Would you be as upset if CERT or IETF exposed the vulnerabilities? With them it would have been exposed up to 2 months ago.
Whether intended or not, this is classic deflection. Don't address the subject, change it to something that fits your narrative.
That's a hard to believe since all your comments center around Google exposing vulnerabilities 3 months after they told Apple about them.
Again, you're on everything and everyone but Apple. For me personally, it's hard to take anything you post without a grain of salt since most of your post are either immediately defensive of Apple or "yeah but company X does this". Just my opinion.
ON TOPIC: Google could save itself a lot of forum grief by reporting to CERT and IETF and letting them work within their respective 45 & 30 day windows. It might work out better for everyone since the shorter time frame puts more pressure on the companies to address the issue(s); whether through a patch or a notification to customers if more time is needed. That also removes the specter of underhandedness from the Project Zero team.
Are they direct competitors to any of the companies named in this article? No, they are not.
----------
I have no problem with anyone pressuring Apple to fix bugs, I just don't like that a direct competitor has deemed themselves an authority on exposing them and telling their competitors that they will release possibly unknown bugs to the public domain because they said so. I don't care that Apple is being pressured, or Microsoft for that matter, they should be, but releasing those bugs publicly by a market competitor is scummy. It's typical behavior from Google, they publicly try and tell everyone that everyone else is ****** and that they "do no evil" despite the fact that they are just as if not more underhanded than anyone else.
----------
You, like many others, miss the point. It doesn't matter that Google gives them any time window at all, it's that Google is a direct competitor of Apple and Microsoft and has for whatever dubious reason decided that they are the "good guy" and made themselves the authority on releasing critical bug information on their direct competitors publicly. CERT and IETF are NOT their competitors and do not gain any perceived or realistic advantage by harming Apple, Microsoft or their customers by releasing that info. It's basic logic to realize that Google isn't doing this for the greater good, they are doing it to gain some kind of advantage over the other two by making them the "bad guy" and making them look bad.
So the problem is not disclosing the vulnerabilities, the problem is just the one doing it.
Funny, perhaps it is better to send the vulnerabilities to CERT, Apple and Microsoft would have half the time to fix them. Better for the users and some would not be so pissed off.
fixed that for you.
It's just your point, not the point and I don't think anyone missed that point. The point is mitigating the vulnerabilities so that we all benefit from a safer computing environment.Bolded: Instead of casting unfounded aspersions, you could, I don't know, actually try to find out the motivation behind Project Zero. Cursory internet search would most likely shed some light. Admittedly, it is a lot easier to just assume someone has ulterior motives.
What you call "basic logic" can also be described as unsubstantiated supposition, or more colloquially, opinion
. po-TAY-to, po-TAH-to amirite?
Last edited:
Huh? How is that an example of my logic?
The harsh reality is that, in business, deadlines are deadlines. In fact, in most real-life situations, deadlines are deadlines.
Even in school (a less harsh real-life environment), students are taught that if you miss deadlines, there are consequences. Usually, it is the very irresponsible and/or immature people that fail to accept the consequences and blame everyone but themselves for having to deal with those consequences.
Edit: And how is a firm 90 day deadline arbitrary? What would be arbitrary is if Google extended the deadline for some, but not others. I'm not sure you understand the meanings of the words you're using...
Last edited:
I've never had my Mac Pro exploited by any of these things.
But I have daily problems with Yosemite, none of which are fixed to this day.
The fear of imaginary or potential threats is not necessarily a bad thing.
The fear that I can't use the machine daily is a daily REAL problem that already exists.
PRIORITIZE APPLE!
But I have daily problems with Yosemite, none of which are fixed to this day.
The fear of imaginary or potential threats is not necessarily a bad thing.
The fear that I can't use the machine daily is a daily REAL problem that already exists.
PRIORITIZE APPLE!
And of course in typical fashion Apple only fixes the bugs in Yosemite. Because heaven knows, the networkd bug is not to be found on Mavericks or Mountain Lion! (Guess again, Apple!)
Yes, I understand perfectly well what that word means; 90 is just a number. Why not 100 days or even 80 days. Please get me the studies telling me how one number is better than the next. I'm going to bet you'll be digging a while. So, yes, arbitrarily set at 90 days, so bugs won't linger unfixed.
The ultimate goal of the number is security, not security at all cost. It is not a dogma were no situations can ever alter the number.
The simple matter is that this didn't increase security by releasing the technical details (not just the bug's existence), the stated goal, and Microsoft or Apple releasing a not fully vetted patch had a good chance to disrupt security and stability of existing system. A bigger failure. A failure mind you that Google would not have to bear at all.
So, Google had basically nothing to lose in doing what they did.
Considering the potential massive damage a not fully tested patch could inflict and the fact that the bug wasn't critical (like say the goto bug or the heartbleed bug), a few more days of delays would not have made a big difference.
That's how it works in the real world; not patch as you please, because we don't care what happens elsewhere, world.
If Apple or Microsoft were totally ignoring the fix, you'd possibly have a point, but as things stand, you do not.
kewl name
Reminds me of a Amiga game I play ..... meh....
I thank Google for this... the public has a right to know after 90-days.. We use the companies OS, weather it be Google Chrome, Windows, or OS X, its still should be fixed given time...
Who know what would happen if left "non published"... Ya, Apple may fix it eventually, but who knows when that will be.
Kind of like 'twisting your arm till u cry', type of issue ain't it ... Ouch.. painful...
Reminds me of a Amiga game I play ..... meh....
I thank Google for this... the public has a right to know after 90-days.. We use the companies OS, weather it be Google Chrome, Windows, or OS X, its still should be fixed given time...
Who know what would happen if left "non published"... Ya, Apple may fix it eventually, but who knows when that will be.
Kind of like 'twisting your arm till u cry', type of issue ain't it ...
Ouch.. painful...