Independent developers don't have to patch something with millions of lines of code.
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
Independent developers don't have to patch something with millions of lines of code.
Google is doing this to their competitors. You can excuse that behavior all you want, but Google wouldn't invest the time, resources and money into finding things like this and giving an ultimatum. If you think Google is doing this for absolutely no gain to them by making competitors look bad you're grossly naive. Google doesn't give a damn about you, me, or anyone else except themselves. NO for profit company does anything other than try to make as much money as possible and make their competitors lose to them. I have no issue with bugs being found, I do have an issue with a direct competitor making themselves an authority and releasing bugs that can directly harm millions of people where they may not have been widely known enough to be that serious of a threat. You can ignore the fact that it's a competitor doing this, but that doesn't change the facts that Google has made themselves and authority where they have no business doing so and demonstrate yet more hypocrisy.
It's not "how bad Google is" (from my POV at least, and what I infer from some others' comments), it's questions about how they are (or could be) handling the built-in conflict of interest here.
None of the other bug-reporting, releasing groups I know of are also OS and major software vendors themselves.... ...who stand to gain market share against their main competitors if they can create a perception of security problems with said competitors.
Anyone who can't see ways Google could game their report releases despite their "rules" (90 days and other) is taking a narrow angle view. E.g., how is it decided (and how consistently is it decided) that a bug is "now" verified and it's time to start the "countdown clock"? And for that matter, how "natural" a standard are the rules they've chosen? Should there be different considerations based on various parameters like whether exploits require personal access to hardware vs those which can be launched from anywhere? The type of threat posed? The probable degree? The level of sophistication required to implement and carry out the threat?
Google's well aware of MS's "Patch Tuesday" routines - which are only altered if an emerging threat requires an emergency release, and the current MS potential exploits didn't rise to that threat level of altering a schedule that users have come to understand and IT Dept's anticipate and plan internal workloads and tweaks around.
So is it an accident, strict "rule-following" or gamesmanship that the clock was set to run out two days before a Patch Tuesday? I don't think the degree of transparency about how the whole process works that being in Google's position here would call for is being revealed. At least it wasn't in this article.
Also, like many in the thread, I'm not up to speed with data about actual examples or "lack of examples," but I believe AI should have addressed the degree to which Google releases the same kind of report on threats in Android, Chrome and any of their own services as a gauge to "how level a playing field" they're on in this arena.
So not just a hate fest. There are legit q's left unanswered.
What matters to me and other consumers is that issues are found and are addressed as soon as possible. Thinking deeper about the reasons and all that extraneous stuff becomes moot since as a consumer that isn't important when compared to security issues being found and addressed. To imply otherwise is to assign more importance to things that simply do not carry that importance.
Ah, after looking more into it I guess it's only Yosemite that will receive the fix.
Do you mean that Mavericks is vulnerable? Or is this a Yosemite-specific flaw?
I'm not sure if Mavericks is vulnerable, but fixes for other exploits found are already patched in Yosemite. I don't see it mentioned anywhere that Mavericks is getting patched.
My CENTOS that was released last year will be supported until 2024. LTS linux is the place to be.
Yes they do, and we thank them.
Google is pretty split between Linux and OS X I don't know which is more dominant right now.
----
On topic: I have zero problem with this policy (90 Days) I want SW companies scared of both public outcry and security flaws. I don't care if you patch on a particular day I want security patches done and tested yesterday. All these OS's call home and can be patched at will by their respective companies, to much of the world runs on IT to let thing linger.
Maybe they should test properly before releasing to the public? No excuses. At first I was a bit annoyed at Google for this, but if it forces Apple to sort themselves out, then good.
Apple's approach to software in the last 3 years can best be described as sloppy. They don't seem to have the resources to fix issues. Very, very poor.
But they do have the resources but choose not to for whatever reason. That's the most frustrating part.
While I agree with your opinion about CERT's goal of increased security over strict timelines, your characterization of "routinely" is disingenuous. Why? Because you know it to be untrue. Their disclosure policy is easily obtained through a cursory google search:
"Vulnerabilities reported to the CERT/CC will be disclosed to the public 45 days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors."
In the very next sentence is where you only present half the truth to further your narrative:
"Extenuating circumstances, such as active exploitation, threats of an especially serious (or trivial) nature, or situations that require changes to an established standard may result in earlier or later disclosure. "
There's nothing about "routinely" in anything I've quoted nor is it in the rest of the document. No routinely over 45 days. No routinely under 45 days. Again, you are right about CERT not being dogmatic about disclosure. No need to corrupt their message to make a point. CERT does not distribute the exploits, which I don't think Google should do either. It's the only problem I have with what Project Zero does.
In case anyone is interested: http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm
I don't agree with exploit exposure, but I doubt Google's motivation is as nefarious as you think it is. Why? If they were doing it to embarrass their competition, they could have done it a long time ago, and multiple times. They've found a number of vulnerabilities that vendors have fixed and the public was none the wiser. So would you rather the vulnerabilities be unreported and possibly exploited, or are you better off that Google reported them to Apple and other vendors?
Vulnerabilities: https://code.google.com/p/google-security-research/issues/list?can=1&q=&num=100&start=0
Again, if they were out to embarrass, there were plenty of chances to do so prior to this most recent disclosure.
Without a push like publicly releasing the security flaw, Apple and others do nothing to fix them. If simply making them aware of the issue got the problem solved, they'd do it. Instead reporting security flaws rarely gets Apple to take action and fix it. It's not until they're made public that they have to act to cover themselves.
We've been exploiting a huge security flaw in OS X (and all Linux really) for years in the commercial software we sell to government agencies all over the world. Apple is aware of it (we've demo'd it to them and even work with their government sales guys) and they have done nothing to patch it. If we were to make it public, they'd likely act to take care of it instead. Since it's only available to law enforcement, they seem less worried.
Roundups
Zero day wonderability!
Zero dirt publishability!
https://code.google.com/p/chromium/issues/list?q=label:Cr-Security
https://code.google.com/p/chromium/issues/list?q=label:Cr-Security-UX
Chrome OS security holes found, patched | ZDNet with emphasis:
Meet Project Zero, Googles Secret Team of Bug-Hunting Hackers | WIRED
Zero article readability!
And of course Apple security updates are not limited to Yosemite.
Open source
+1
Apple security updates
Related: Mavericks Support - EOL When? Observations on support for Mac OS X v10.4 Tiger and greater
Mavericks and earlier
https://code.google.com/p/google-security-research/issues/list?can=2&q=label:vendor-Apple
Issues 92 and 130 involve networkd, which first appeared in Mac OS X 10.7; and so on.
Apple prerelease testing of security updates is normally private.
+1
Interesting.
Zero day wonderability!
Zero dirt publishability!
https://code.google.com/p/chromium/issues/list?q=label:Cr-Security
https://code.google.com/p/chromium/issues/list?q=label:Cr-Security-UX
Chrome OS security holes found, patched | ZDNet with emphasis:
"
At Google's own Pwnium hacking contest and HP Zero Day Initiative's (ZDI) annual Pwn2Own hacking contest , three new sets of security problems were found in Chrome OS... and then immediately patched.
"
Meet Project Zero, Googles Secret Team of Bug-Hunting Hackers | WIRED
"
When Hotz dismantled the defenses of Googles Chrome operating system earlier this year, by contrast, the company paid him a $150,000 reward for helping fix the flaws hed uncovered. Two months later Chris Evans, a Google security engineer, followed up by email with an offer
"
Zero article readability!
And of course Apple security updates are not limited to Yosemite.
Open source
+1
Apple security updates
Related: Mavericks Support - EOL When? Observations on support for Mac OS X v10.4 Tiger and greater
Mavericks and earlier
https://code.google.com/p/google-security-research/issues/list?can=2&q=label:vendor-Apple
Issues 92 and 130 involve networkd, which first appeared in Mac OS X 10.7; and so on.
Apple prerelease testing of security updates is normally private.
+1
Interesting.
Bluetooth vulnerabilities
Project Zero
Amongst the publicly listed issues where the project deadline was exceeded:
More than a week earlier, 2015-01-12, resulting from joint work:
Project Zero
Amongst the publicly listed issues where the project deadline was exceeded:
- Issue 136: OS X IOKit kernel memory corruption due to bad bzero in IOBluetoothDevice automatically derestricted on 2015-01-21.
More than a week earlier, 2015-01-12, resulting from joint work:
- Roberto Paleari's blog: Time to fill OS X (Blue)tooth: Local privilege escalation vulnerabilities in Yosemite
- Enzan no Metsuke: Time to fill OS X (Blue)tooth: Local privilege escalation vulnerabilities in Yosemite
"
The issues have been reported to Apple Security and, since the deadline we agreed upon with them expired, we now disclose details & PoCs for four of them (the last one was notified few days later and is still under investigation by Apple).
Disclosure timeline
02/11: Notification of issues 1, 2 and 3.
23/11: No answer received from Apple, notification of issue 4. As no answer was received since the first contact, propose December 2 as possible disclosure date.
25/11: Apple answers requesting more time. We propose to move the disclosure date to January 12.
27/11: Apple accepts the new deadline.
05/12: Contact Apple asking for the status of the vulnerabilities.
06/12: Apple says they're still "investigating the issue".
23/12: Notification of a new issue (#5), proposing January 23 as a tentative disclosure date.
06/01: Apple asks for more time for issue #5. We propose to move the disclosure date to February 23. We remind our intention to disclose the 4 previous issues on January 12.
12/01: No answer from Apple, disclosing first 4 issues."
Disclosure timeline
02/11: Notification of issues 1, 2 and 3.
23/11: No answer received from Apple, notification of issue 4. As no answer was received since the first contact, propose December 2 as possible disclosure date.
25/11: Apple answers requesting more time. We propose to move the disclosure date to January 12.
27/11: Apple accepts the new deadline.
05/12: Contact Apple asking for the status of the vulnerabilities.
06/12: Apple says they're still "investigating the issue".
23/12: Notification of a new issue (#5), proposing January 23 as a tentative disclosure date.
06/01: Apple asks for more time for issue #5. We propose to move the disclosure date to February 23. We remind our intention to disclose the 4 previous issues on January 12.
12/01: No answer from Apple, disclosing first 4 issues."
I'm not implying anything other than I think it's scummy for a COMPETITOR to decide they are the authority on their COMPETITORS software. Google has no right or justification for waltzing around like they are the good guy exposing all of this to your regular unskilled ******* script kiddie while they steadfastly believe that they can leave a huge portion of their Android customer base completely out in the open. Google are being the worst kind of hypocrite, a smug one. Get the bugs fixed is a great idea, Google being a smug ass about it is what I take issue with.
Yes, they are since they have thousand of computers using that software
How are they leaving a huge base of Android customers out in the open?
Considering nothing like that was or is going on, and only various people potentially reading that into it themselves based on their opinion, it seems like it's all good from a consumer point of view.