Questioning Google's Disclosure Timeline Motivations 73
An anonymous reader writes "The presence of 0-day vulnerability exploitation is often a real and considerable threat to the Internet — particularly when very popular consumer-level software is the target. Google's stance on a 60day turnaround of vulnerability fixes from discovery, and a 7-day turnaround of fixes for actively exploited unpatched vulnerabilities, is rather naive and devoid of commercial reality. As a web services company it is much easier for Google to develop and roll out fixes promptly — but for 95+% of the rest of the world's software development companies making thick-client, server and device-specific software this is unrealistic. Statements like these from Google clearly serve their business objectives. As predominantly a web services company with many of the world's best software engineers and researchers working for them. One could argue that Google's applications and software should already be impervious to vulnerabilities (i.e. they should have discovered them themselves through internal QA processes) — rather than relying upon external researchers and bug hunters stumbling over them."
You suck (Score:5, Insightful)
If your company is producing security critical software and doesn't have a plan for quickly dealing with bugs you suck.
-1 Flamebait (Score:5, Insightful)
For article. Sadly you can't moderate an article.
Just Google? (Score:5, Insightful)
Why single out Google? Shouldn't traditional software vendors have also run programs through QA?
Re:You suck (Score:5, Insightful)
Also, even if they can't patch it quickly the point is to inform users so they can take appropriate precautions.
Re: -1 Flamebait (Score:2, Insightful)
Agreed. Submitter sputtered the industry line, but if the industry wanted different standards they should try setting *some* standards instead of pretending that it's OK to ignore vulnerabilities.
You're right, 7 days isn't good enough (Score:3, Insightful)
A vulnerability that is already being exploited needs to be fixed right away. It's called 0-day for a reason, not 7-day. It should be disclosed immediately to force the vendor to do something about it.
What?! (Score:5, Insightful)
a 7-day turnaround of fixes for actively exploited unpatched vulnerabilities, is rather naive and devoid of commercial reality. As a web services company it is much easier for Google to develop and roll out fixes promptly — but for 95+% of the rest of the world's software development companies making thick-client, server and device-specific software this is unrealistic
Hello there, mr/ms/mrs anonymous COWARD, what are you saying there? It COSTS TOO MUCH to prompty (as in a week) fix ACTIVELY EXPLOITED vulnerabilities? When you get the actual problem handed to you on a silver platter? What company do you work for?
Slower? He's Saying Slower?!? (Score:4, Insightful)
a 7-day turnaround of fixes for actively exploited unpatched vulnerabilities, is rather naive and devoid of commercial reality.
I read that and I was thinking, "Well, yeah, sure - I shoot for one hour and can't recall the last time it took more than a day to get a critical bug patch out, but that's not really reasonable for everyone. The team I work on is pretty focused on keeping the tracks polished so we can get high priority things through. I think 7 days is OK. It could be better, but it's OK. And Google isn't even saying it will take 7 days, they're saying 7 days is the max. But, whatever, I guess -- ultimately agitating for faster patches is something I support."
for 95+% of the rest of the world's software development companies making thick-client, server and device-specific software this is unrealistic.
What?!? You mean it's not realistic to get the patch available within 7 days? I mean, obviously you can't expect users to have their systems patched immediately, and sometimes a third party (like a walled garden approval path) can lock you out. But is the writer saying 95% of companies can't even have a patch pushed for release in 7 days?
If that is true, we, as a society, need to drop what we're doing and focus on security, build management, QA workflow, whatever it is that is making that a reality. 7 days is acceptable. 95% of companies can't hit 7 days? First, that is not true in my experience. But if it is? That is not acceptable, if it is true. There really are bad people out there trying to root our electronics. Seven days to get a patch out for an actively exploited in the wild vulnerability is enough. Work the problem. Figure out why you can't hit that number, and fix it.
Naive and devoid of reality? (Score:4, Insightful)
I think what you're saying, is that if someone is going around stabbing people in the heart, and if a doctor says these victims all need immediate medical attention (even the victims which are in isolated areas far from hospitals), then that doctor is being naive and devoid of medical reality.
I personally think you should quit blaming the doctor for the unfairness and horror that is inherent in the situation. Declaring the urgency of a problem being addressed, isn't "naive". It's not naive, even if addressing the problem is incredibly hard or even if it's effectively impossible.
If the doctor truly thinks the victims all really will get "immediate medical attention" then he'd be naive. But advising it isn't naive. Yelling at people "get that victim to the ER as fast as you can!" isn't naive. Telling people that heart stab wounds are very serious, isn't naive.
And the analogy with Google here, is that you just got stabbed in the heart, they're advising and hoping you get immediate medical attention, and 7 days from now, if your wife asks Google if they've seen you lately, they're going to tell your wife, "I heard he got stabbed in the heart last week. You took him to the hospital, right? If not, you better get on that, right now." You're concerned Google is going to scare your wife?! Be concerned that you're not at the hospital yet!
You think Google is being naive with unreasonably high expectations, but the need for those high expectations isn't their fault!
Re:Just Google? (Score:5, Insightful)
Most other companies doesn't have well funded FUD campaigns directed against them.
Re:You suck (Score:0, Insightful)
Explain that to a PHB project manager [1] who has a mantra: "Security has no ROI... Security has no ROI", and refuses to pay for anything other than the basic QA when it comes to security. If there is a flaw discovered, usually it gets flagged as "FNR", or fixed in next rev or it just gets downchecked as "nobody will find that" or "too expensive in man-hours to fix right now."
A lot of companies I encounter are purely reactive. Sales/Marketing wants "x" feature list for the next rev, which cause the managers to crack the whip, so it can be gotten out on some arbitrary release schedule, and if it builds, it is a lucky thing, much less actual security be used.
Lawsuits are not going to work -- EULAs have been upheld in court. The only thing that really does is OSS projects because (and this is in general) there is not a PHB demanding all devs get 10,000 lines of code written a day or else they will be chucked for a H-1B, or the whole dev divison offshored.
It is only going to get worse. There is -zero- penalty for failing to have secure code. This by Google is the -only- thing out there that might spur vendors to actually do stuff. Otherwise 0-days will never be fixed, period. We saw this shit in the 1990s with UNIX vendors who were too lazy to patch holes, forcing sysadmins to use BSD binaries, and it only got worse.
[1]: A manager that likely has staffed the team with $30,000 a year H-1Bs because of the payroll tax bonus, so in actuality, there might be 1-2 people actually pulling their load, the rest are watching Bollywood flicks.
Vendor's processes not relevant (Score:5, Insightful)
As a user, I don't care about the vendor's ability to fix it quickly. Really I don't. That's their problem. My problem is that my systems are vulnerable to compromise and I have to do something about it. I need to know what the vulnerability is, in enough detail to understand it myself, and I need to know the possible workarounds (not just the vendor's recommended one(s), which is another reason I need to know what the vulnerability actually is so I can understand all the other possible ways of dealing with it). I need to evaluate my options and take whatever steps I need to to protect my systems. If the vendor needs a month to get the fix through their change-control process, I still need to protect my systems today.
The vendor's advice will be based on their most-likely scenario. Problem is that my situation may be radically different from the vendor's most-likely one. There's definitely going to be local considerations even if my situation's one the vendor's workaround covers. I need to understand the vulnerability to be able to evaluate it intelligently. It may not even be relevant to my setup. If it is, I may have less-intrusive workarounds (eg. for the SSH OTP authentication bug, if we've got a purely internal network that isn't accessible to the outside world or the Windows desktop portion of the network it may be less intrusive to just monitor for attempted exploits and defer doing anything until I see someone having gotten past the air gap rather than changing an authentication method that a lot of people depend on and that can't be exploited easily without being physically in the building). And if I need to take drastic steps like disabling the vulnerable SSH authentication method, I may have clients who insist they must be able to use it (maybe because their systems are based on it and they need my systems to integrate with their authentication because I'm providing services to them) and I need to be able to intelligently discuss exactly what's wrong and why it's simply not possible to use that method without being vulnerable and we've got to change to a different method despite the disruption. I can't do that unless I understand the vulnerability.
Notice that in all the above I haven't mentioned the vendor at all. Like I said, the vendor isn't relevant at all. It's my systems that're vulnerable and me that has to do something about it. If the vendor already has a fix then well and good, but if they don't it doesn't change my situation. When vendors say they need more time, they're asking me to leave my systems vulnerable without telling me they're vulnerable. Sorry, but no. Not, that is, unless they're willing to shoulder 100% of all the costs resulting from that vulnerability being exploited. Not just direct costs, things like the costs of lost business and clean-up if the vulnerability is exploited and liabilities I may incur because of the compromise. If a vendor isn't willing to take on that liability, then they don't get to tell me I shouldn't have the information I need to protect myself from that liability. If they don't like it... this is the sound of the world's smallest violin, playing the world's saddest song just for them.
Re:Perhaps Google does tell companies... (Score:2, Insightful)
If you say "I'm telling you privately but going public in 7 days" it sounds like a threat and the most likely response if a lawsuit or the police hammering on your door. Even if you don't say anything about going public there is a fair chance of that happening. Your actions are pretty risky.
Unfortunately unless the company has a history of dealing with security bug reports in a timely and proper manner the most responsible thing to do is just post about it anonymously to one of the full disclosure mailing lists. Morally you can't sit on it but shouldn't be expected to risk your own liberty and employment either.