Submitted by Microsoft has heavily criticized Google and its 90-days security disclosure policy after the firm publicly revealed two zero-day vulnerabilities in Microsoft’s Windows 8.1 operating system one after one just days before Microsoft planned to issue a patch to kill the bugs. But, seemingly Google don’t give a damn thought.
Once again, Google has publicly disclosed a new serious vulnerability in Windows 7 and Windows 8.1 before Microsoft has been able to produce a patch, leaving users of both the operating systems exposed to hackers until next month, when the company plans to deliver a fix.
First, this article makes the usual mistake of calling these vulnerabilities “zero day”. They are not zero day. They are 90 day. A huge difference that changes the entire context of the story. Microsoft gets 90 days – three months – to address these issues. I do not see why Google has to account for Microsoft’s inflexible security policies which leave users in the lurch.
Second, note that Google also disclosed two OS X vulnerabilities alongside the Windows one. Nobody seems to be talking about those.
Third, Google, how about addressing your own security problems.
Perhaps, a well known government agency needed more time to move their exploit tools to an other unknown exploitable vulnerability(/feature) ?
Just wondering.
Unknown exploitable vulnerability(/feature) as in below 90 days known, in case handled under responsible disclosure, or probably forever in case operated under Microsoft’s coordinated vulnerability disclosure.
“Microsoft planned to issue a patch a day later” sounds like a reaction caused by responsible disclosure. Doubts are huge they would even have had started working on a fix without any deadline like the case if handled under coordinated disclosure.
As OSAlert doesn’t link the article, I assume they refer to the Hacker News one from Friday about the CryptProtectMemory bug.
That statement is a joke. Google has just a handful of employees in Project Zero. To assume that they were the first ones to discover the vulnerability is preposterous. So the reality is that users have already been exposed for an unknown amount of time.
Up to now, users were clueless and defenseless against this vulnerability. Now they have the information they need to accurately assess the security of their systems and protect themselves (as Microsoft failed to protect them).
Agreed, it also forces Microsoft’s hand to try and fix the issue, which is a very good thing even if you don’t use Windows. Less vulnerable systems equals to less botnet nodes, less spam, etc..
I wish I could upvote you a trillion times. Well f*cking said!
(I know this opinion is highly unpopular here, but…)
It is not Google’s problem that OEMs suck so much. By now everybody should have known that leaving digital equipment with stock firmware leads to huge security risks. People who care use third-party firmware, and those who don’t are probably OK with all kind of security issues they have because they didn’t want to invest their time into researching the Android firmware situation.
Sure, it would be nice if Google could bind OEMs into updating software, but this hardly seems possible in regard of Android market revenues.
FWIW I regard the problem of OEMs violating GPL by not publishing their changes to Linux kernels runnings on their hardware as much more of a problem then sluggish updates of crapware they put on top of stock Android. Probably Google could help its customers much more by forcing OEMs to publish diffs.
P.S.: Microsoft is upset that they aren’t allowed to keep customers vulnerable forever. No real news here.
Google could have made part of Android license, that OEMs were forced to provide updates.
However even Google doesn’t respect its own Nexus customers.
How so? My first gen Nexus 7 just got Android 5.0.
My second gen Nexus 7 LTE still has not.
In fact, it is currently 3 minor releases behind all the other Nexuses.
*NO* 3G/LTE Nexus 7 had received it since it does not exists yet (https://developers.google.com/android/nexus/images) and this is BAD.
Mine too.
After two days with 5.0, I would have considered more respectful to keep me on 4.4 (with security patches) than this acrid Lollipop.
(Yes, this is a rant !)
Which obviously wouldn’t impact on Android acceptance, would it? Sorry, I forgot that we live in a wonderland where economics and market rules don’t influence technology…
Seriously, Google couldn’t even force OEMs into making their crapware optional on firmware with current update cycle, how would it even dream about forcing anyone into anything? The whole smartphone market (with notable exceptions of Apple and Jolla) depends on the fact that every smartphone is completely consumed in two years of usage. If the value of 2-years old smartphone would remain non-zero for average consumer, the whole model of rapid release cycles with yearly updated product range would fall apart.
Once upon a time I used to work for a certain Finish mobile manufacturer, so I am well aware how the market works.
Still, Google is the one to blame, by following the same approach as other OS providers were doing, instead of a more rigid one.
So your problem with Google is that it is just another mobile OS vendor? OK, accepted.
“Which obviously wouldn’t impact on Android acceptance, would it?”
I don’t see how Google’s motives rationalizes their non-motivation in another area or absolves them of it being their problem.
Yes, Android would not be as widely adopted if OEMs needed to properly support it. And? All that tells me is that mass adoption and market dominance are far more important to Google than secure, up-to-date systems in the hands of its users.
Which is rather obvious: what is the benefit of developing perfect OS with no users?
No one is asking for the perfect OS. What is being asked for is basic security support. You are rationalizing away a real need and desire.
Hell, I don’t see why, according to your logic, one couldn’t say: “it’s not Apple’s responsibility to fix any perceived stability issues in their OS because they value getting more new features to as many users as quickly as possible over stability and that’s perfectly within their rights.” In fact, according to your logic, I can’t see how anyone could ever be responsible for ever providing any security update of any kind. As long as some business motivation is greater, any company can neglect security to their heart’s content based on your logic.
Edited 2015-01-19 22:01 UTC
This is because you ignore the “old, unsupported” words in my comment. Vendors must fix issues in supported releases, and should make clear what releases are actually supported. I just don’t see why you think this does not apply to Google, unless you state that other vendors should support all of their historical products as well.
The thing Google indeed does wrong is communicating the support policy to general public. I am sure OEMs have the dates and support status details, but general public is entitled to access this policy as long as Android is marketed as Google’s product.
Nonsense. Every condition you are rationalizing Google’s behavior with are factors that Google willfully creates: when the vast majority of your users are on an “old, unsupported” OS version that’s only 3 years old but likewise for all intents and purposes “no one” is using your “newest, supported” OS version, the burden of security doesn’t just disappear.
Edited 2015-01-20 16:00 UTC
Whose burden? Smartphone users are not Google’s customers – OEMs are. Evidently, Google’s customers don’t care.
P.S.: One could actually state that Google artificially shortens support timeframe to force OEMs into updating firmware for their products.
You keep making distinctions and rationalizations without meaning: Google produces the OS, Google is in the position to best support and update it, Google could require OEMs to update or provide a direct facility for Google to update (Microsoft is capable of doing both), AND Google would receive the greatest benefit (outside of the consumer) from doing so.
That they choose to not do so is entirely the point.
And let’s be clear: even insofar as Google does take the scantest responsibility in providing security updates to its codebase which may or may not actually make it to the consumer, it is woefully insufficient. That they will no longer update Jelly Bean with security updates even though they know it represents nearly 50% of their counted install base and they’ve created an environment where new and future devices will still ship with Jelly Bean is a disservice to their users and software in general, and that should be criticized, not defended.
Edited 2015-01-20 22:42 UTC
ddc_,
Forget about old products, I’m finding that many companies won’t even support their current “supported” products either.
I just bought two brand new VisionTek SSD GoDrives, specifically sold with a 3 year manufacturer warranty, to build a raid array. After 3 months one of them had a failure and stopped showing up in the bios. It sucks that one died, but I can just RMA it and get another, right? Well, the unbelievable scumbags at VisionTek RMA department are voiding their own official warranty by adding new unlisted terms that the manufacturer warranty does not apply to new products sold through other merchants. Here’s the thing though, there is no such exclusion or list of approved merchants in the warranty…so it’s impossible to know that they won’t honor the warranty ahead of time. WTF is that about?! I’m positive it’s illegal, but how many of us really have the legal expertise or time to fly to Illinois to go to court over a ~$150 purchase? Their warranty was the main reason I took a chance with an unproven company, but I never figured VisionTek would weasel out of their warranty obligations.
I bought a brand new Lantronix Spider Duo device for remote PC access. It’s a great little device, yet a misconfiguration inside the firmware means it fails to send WOL as a broadcast packet, which is required for many/most computers to wake up in magic packet mode (as opposed to directed packet mode, which wakes up on any traffic even without a magic packet). I contacted Lantronix, they confirmed the issue, but stated they would not be fixing it in this product. Come on guys, I handed in the fix myself, add “-b” to the etherwake command. The product is still being sold and it isn’t cheap, it should be supported. The firmware is GPL because it runs linux, but the hardware is closed unfortunately so I’m dependent upon them for a fix which isn’t forthcoming.
We bought a certified used Honda Odyssey from our Apple Honda dealer with extended warranty (at a cost of ~$2K). However the vehicle started exhibiting several problems, the biggest problems being unable to get the car out of park to drive and the car not turning off completely because the ignition gets stuck in accessory mode, so pretty major. I was dumbstruck when they refused to repair any of the mechanical failures under warranty and demanded another ~$1K for repairs. When I declined they demanded I pay a diagnostics fee since I wasn’t going to pay for repairs. This one has my blood boiling and I’m still fighting them over it. What good is a warranty if a company can simply opt out of honoring it?
These are fresh scars, which is why I’m so bitter about it… Man do I hate what companies have become. They promote the illusion of good support, but after sale when you actually need support, they just don’t give a damn.
/rant
Edited 2015-01-20 16:36 UTC
The issue here is that Google are refusing to fix the bug. Even if they do, there may be issues with getting it to customer’s, but the first stage should be to fix the bug.
Which is OK, as it is a bug of old, unsupported release. The problem here is that most vendors ship such “old, unsupported releases”, but that’s vendors’ fault. You get your warranty from vendor, not from Google.
Edited 2015-01-19 15:44 UTC
Yes, Google should focus on bugs in own products first, its performance on this is less than stellar. For example, OpenVPN support in Chrome OS is broken, ticket for this was created years ago, Chromium Team knows about it and it has not been solved yet! It is not a subtle bug: it forces 90% of OpenVPN users to use ugly workaround: to create JSON file with connection params manually or to switch machine into the developer mode and invoke OpenVPN via crosh. The point of Chromebooks is to ‘just work’, not to make users waste their time browsing forums and hacking the official functionality that should work out of the box.
Well, OpenVPN is not exactly mass used product. Those, who need to make their profile into JSON file will do so.
For comparison, the IPSec support in Android still does not support IKEv2 and nobody really cares. Everyone who needs one gets StrongSWAN from Play Store and goes on with their life.
It depends. Business adoption of Chromebooks involves fully operational VPN.
That’s true, but I have yet to see any significant use of OpenVPN in businesses.
What I see instead is usually Cisco or other IPSec-based VPN, occasionally with Citrix thrown in for publishing the apps.
So those who really use OpenVPN will be able to just create JSON profile. Inconvenient? Yes, but not a showstopper. Those who sell Chromebooks to you, will probably do it for you anyway. (You don’t purchase your IT equipment at Amazon or other retailer, do you?)
Waiting for Microsoft to start doing the same for Android, ChromeOS and Chrome.
It would be fun to watch.
Overall I think it’s better for us, users, if companies start forcing each other’s hands with this revelations.
Unlike Microsoft, Google would just patch the code within 90 days.
Actually, Google asks only for 60 days between report and public notification:
http://googleonlinesecurity.blogspot.de/2010/07/rebooting-responsib…
Actually they would just close them without comments.
I think this would be very good. But it is unlikely to happen, as that would be equivalent to Microsoft conceding that their own Coordinated Vulnerability Disclosure program is worthless when it comes to improving security.
What if they all knew about each others vulnerabilities but made a mutual pact to hush them up? Think they’d get fixed? Where would you put your money? I don’t see any harm in Google’s tactics. Information is a good thing. Let ’em embarrass each other. Frankly, I’d greatly enjoy an “arms race” of embarrassments between the likes of Apple, MS, & Google. To h-ll with the blogger’s opinion. Let ’em fight — and pass me the popcorn. I’ll wager the benefit to end-users would far outweigh any potential harm.
Some years ago I worked for a big Spanish telco company, which I will refer to as ‘Tel’. ‘Tel’ is, in fact, one of biggest worldwide in its activity sector.
It was the times of the dot-com bubble, and every year ‘Tel’ was paying a huge amount of money to the USA-based corporation ‘Nets’ for a license of its crappy HTTP server.
This crappy HTTP server had a embedded Java Virtual Machine (JVM). One day, a ‘Tel’ employee find out a bug in the JVM and reported it to the ‘Nets’ guys.
Some days later the ‘Nets’ guys answered that they were unable to reproduce that bug.
The ‘Tel’ guys repeated the process, got the same bug again, and reported it again; and the ‘Nets’ guys, replied again “No bug”.
Ping-pong, ping-pong, ping-pong… An storm was arriving.
Finally, a representative from ‘Nets’ arrived to the ‘Tel’ office. ^A<>
Edited 2015-01-19 15:42 UTC
Or, is Microsoft still fixing XP?
Though Google should update things and/or let Cyanogenmod handle the legacy hardware via one Google Play Services unlock as the last act of support.
That said, Google could be nicer by giving Microsoft 3 “second tuesdays” to patch a bug. Given the large install base, and that patches need to be tested by the users before deploying them enterprise wide, Microsoft can’t just patch and crash.
LOL, XP was released in 2001. Jelly Bean (4.3) was released less than 3 years ago. Google needs to fix that shit.
To be fair, it IS fixed in 4.4 (it’s deprecated code).
The problem is the update situation – which has been Android’s huge-ass, biggest problem for years now.
That’s the point though is that it SHOULDN’T be deprecated code yet. It would be like telling Windows 7 users that if you want bugs fixed, upgrade to Windows 8.
Not really – 4.4 is a free upgrade, where Windows isn’t. It’d be more like comparing it to a service pack.
Several of my devices are still running 4.3. I actually prefer it to 4.4, because Kitkat made hamburger meat of my starred contacts, crippled the ability to transfer stuff to SD cards, and broke a couple of other things that I can’t recall anymore. And by the sounds of it, I’m not sure lollipop is ready for prime time yet. Seems like they need a couple more ‘0.x’ releases to work out all the kinks. Hence, I think 4.3 is the optimal version to be running right now, cuz 4.4 is just a shitshow that added nothing worthwhile for me personally.
Similarly, even if Windows 8 were a free upgrade to Windows 7, I think some folks would rather the old version be patched.
Edited 2015-01-19 21:30 UTC
Then there are tens of millions of folks like me who are stuck at 4.0.4 because our smart phones don’t have 1GB ram.
Uh, they did for 13 years. 2001-2014.
I also recently received a software update for a ten-year-old consumer-grade handheld GPS. The unit was locking up because some new satellite sends a slightly different type of signal.
I’m not sure how that relates to telephone software upgrades though. Are there actual flaws that prevent the units from performing normal smartphone functions? Have old features stopped working due to technical changes to the infrastructure? Or are people demanding additional functions that were never included or promised with their original purchase?
I kind of hope that eventually Google will make Android updates more to more like iOS (as in they control them). Google would announce at Google I/O that the next version of software will no longer be vendor/provider controlled and if an OEM/providor chooses to update its software to that version all updates would then pushed through Google services.
Custom ROMS would still be available for development/hacking/independant.
With that said, I’m not sure what agreements Google has made with the Open Handset Alliance. They could be contractually locked into allowing OEM/Providers dictate what/how/when ROMS are built and deployed.