Google Up Ante For Disclosure Rules, Increases Bug Bounty 134
An anonymous reader writes "In a recent post by seven members of their security team, Google lashed out against the current standards of responsible disclosure, and implicitly backed the recent actions of Tavis Ormandy (who is listed as one of the authors). The company said it believed 60 days should be an 'upper bound' for fixing critical vulnerabilities, and asked to to be held to the same standard by external researchers. In another, nearly simultaneous post to the Chromium blog, Google also announced they are raising the security reward for Chrome vulnerabilities to $3133.7, apparently in response to Mozilla's recent action."
Elite (Score:5, Funny)
Google also announced they are raising the security reward for Chrome vulnerabilities to $3133.7
That's quite the elite sum of money to use as a reward.
Re: (Score:1)
Re: (Score:1, Offtopic)
Google also announced they are raising the security reward for Chrome vulnerabilities to $3133.7
That's quite the elite sum of money to use as a reward.
Pre-WHOOSH, because I know they are coming.
Re: (Score:3, Insightful)
And also, it's contradictory to what google did earlier this year. They released a zero day for windows [threatpost.com] and gave microsoft hardly a week to patch it. And as a bonus, they made the disclosure public on a Sunday.
I am all for more industry standard accountability, but this looks very one sided and google choosing to pick the instances where it gets a good publicity.
Re: (Score:2)
I work on Sundays, why can't Microsoft? Do I get to use their software for free on the weekend? No? Does malware take off on Sunday? No?
Screw 'em.
Re: (Score:2)
Sleep? Weekends? (Score:2, Interesting)
Microsoft OS and App vulnerabilities are the only internet currency better than eGold. If you travelled in those circles you'ld see how bad the situation is. I've been there and back, so I'll tell ya: it's bad. Bad. Really, really, really bad.
If you'll pay $500, there's folks out there who will deliver the contents of your own email inbox unedited, for as far back as it goes, externally and without assistance. The most honest of them will sell you that info and let it go, but we all know there's a lot
Re:Elite (Score:5, Informative)
Looks like someone needs to RTFA.
This article is basically laying out a policy Google will follow in the future. Here is the most critical bit:
A lot of talented security researchers work at Google. These researchers discover many vulnerabilities in products from vendors across the board, and they share a detailed analysis of their findings with vendors to help them get started on patch development. We will be supportive of the following practices by our researchers:
Now that "zero day" (well 5 days really) the Googler gave Microsoft was only because Microsoft would not commit to fixing it. That is perfectly consistent with the article, which points out "responsible disclosure" is a 2 way street and only works when the person with the vulnerability acts responsibly as well (which Microsoft didn't in this case). You could argue that he should have set a deadline regardless of whether Microsoft agreed to it, but I would not say they are contradicting themselves. They also point out in the article that responsible disclosure isn't always the best route. So I'm going to have to support Google in this article, which is simply about laying out their "supported" disclosure policy for their security researchers in the future.
Re: (Score:2, Insightful)
Now that "zero day" (well 5 days really) the Googler gave Microsoft was only because Microsoft would not commit to fixing it. That is perfectly consistent with the article, which points out "responsible disclosure" is a 2 way street and only works when the person with the vulnerability acts responsibly as well (which Microsoft didn't in this case).
that is twisting the truth more than a little. MS said they would get back to him with a timeline by the end of the week, he then went and published it anyway. the irresponsible party in that instance was definite Tavis Ormandy.
Re:Elite (Score:4, Insightful)
Actually, his comment was entirely accurate.
I've reported dozens of critical vulnerabilities in Microsoft software over the years, and I still have multiple open cases with Microsoft security, this particular case wasn't as simple as you have assumed. I would not be so presumptuous to explain the ethics of your work to you, but evidently you believe you're qualified to lecture me in mine.
If I were to read the sensationalised lay-press coverage of your latest publication or project, would it prepare me to write a critique of your
work?
Re: (Score:2)
Your ethics are your own business, unless of course your actions potentially harm other people. Nobody elected you as their Internet Security Guard, so drop the elitist attitude.
Re: (Score:2)
You didn't elect me your doctor either, but I'm sure you would like me to tell you if you water supply was poisoned.
Re: (Score:1, Informative)
Re: (Score:1, Troll)
It was a potential conflict of interest [wikipedia.org], given that he is a paid employee of Google who works as a security engineer. If this was inconsistent with Google's policies, there is definitely a problem, the problem would have been Tavis' fault (not Google's), but it would be up to Google to repudiate the actions if it believed Ormandy was not in compliance.
This article instead suggests that Google's policy is consistent with Tavis' actions, so it really doesn't matter.
Which is fair, but I don't see this new pol
Re:Elite (Score:5, Interesting)
He actually gave his reasons for disclosure in the disclosure itself.
Hcp vulnerabilities are a well known attack vector for Windows, and given that the specific vulnerability he found has existed in Windows XP for 9 years, he felt it was very likely that black hats had found the same technique and as such there was a very high likelihood that it was being actively exploited in the wild. I'm sure the ease with which it can be executed factored in as well - it's literally just a one-line hcp url with execution code in it. Therefore, he felt full disclosure so security professionals could begin mitigating the issue (i.e. disable help center) was more important than giving Microsoft ample time to fix the problem.
Personally, I agree. Microsoft has a history of sitting on high-severity vulnerabilities for years if they aren't disclosed publicly, and this was an extremely easy to execute exploit. The prudent course here was to get the information out ASAP, with little more than a courtesy call to Microsoft before he did.
Re: (Score:1)
Naw, an elite sum would be $31,337.
Which would seem more appropriate, if the security issue has to be exploitable to get it at least.
$3133 is chump change compared to what, shall we say, sale of a security flaw to others with ahem questionable intent, would probably garner (at Google's expense)
Well done. (Score:2)
That's the joke.
NERDS (Score:3, Funny)
NERDS!
Re: (Score:2)
Yes, we are. Sorry you're too illiterate to read the site's masthead. The NASCAR site is somewhere else, Bubba.
I just found a bug... (Score:5, Funny)
I just found a bug in Gmail. We should talk.
Sincerely,
Chinese Hacker
Re:I just found a bug... (Score:5, Insightful)
I just found a bug in your government. We should square up.
Sincerely,
Google
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Dear Google,
That's not a bug, that's a design flaw^^^^^^^^^^^feature.
Sincerely,
Microsoft
Re: (Score:2)
Re: (Score:3, Funny)
3000 yuan is a fairly significant amount of money in China.
Karma be damned, but that's like bragging about being the skinniest kid at fat camp.
The Biggest Loser (Score:2)
that's like bragging about being the skinniest kid at fat camp.
Apparently being the skinniest kid at fat camp is important to anyone who watches NBC's The Biggest Loser. Whoever loses the most percentage of body weight wins. And in any case, being the skinniest at fat camp is better than being the skinniest at concentration camp.
This is good competition (Score:5, Insightful)
Re: (Score:2)
The world gets better apps, Google gets to spread more ads, the SC community learns from bug fixes.
I find googles views on privacy and their past mistake to point at some deep issues.
Better than DRM lock in/out turn off stagnation with MS and Apple for now.
Re: (Score:2)
This is a sign of a truly competitive market. When Chrome and Mozilla are competing to the point where they need to bid on how much they pay for people to find flaws in their own software then there's serious competition. And the result is that we, the consumers, benefit the most. This is market dynamics with honest companies at their best.
There's just so much wrong with your characterization of these bounties as "truly competitive" that I don't know where to begin.
In reality, the only competition these bounties represent is a competition for free publicity and goodwill.
Re: (Score:2)
Re: (Score:2)
I suspect a check from Knuth would be at least an order of magnitude harder to get than one from Google.
Re: (Score:1, Troll)
Or for the glass half empty types: Google and Mozilla aren't willing to pay more than $3134 to eliminate a remotely exploitable vulnerability that could be potentially disastrous for their users!
Re: (Score:2)
Or for the glass half empty types: Google and Mozilla aren't willing to pay more than $3134 to eliminate a remotely exploitable vulnerability that could be potentially disastrous for their users!
should read: "... aren't willing or able to pay more than $3134 ... "
Re: (Score:1)
Mozilla is a foundation, not a company. That is, if we exclude the corporation subsidiary that deals with sponsorship etc.
So, this is not some capitalist ideal of two companies competing for our benefit, rather a very non-capitalist foundation that is encouraging what capitalism discourages. If Mozilla didn't exist, Google might not have bothered to up their reward.
RS
Re: (Score:2)
So if I were a conscienceless skilled hacker and discovered a vulnerability, then in a proper free market I'd be free sell it to the highest bidding criminal?
60 days = upper bound, not average (Score:5, Insightful)
I'm sure a lot of people here will lament that 60 days is way too long to release a fix for most vulnerabilities, and I think that's true. On the other hand, it's probably a "reasonable upper bound" for very complex problems like the TLS session re-negotiation vulnerability, which required coordination between multiple vendors and the IETF in order to fix.
In other words, if you think you should get a 60-day head start to fix a security bug, your bug had better be at least as complex as CVE-2009-3555.
Re: (Score:1, Insightful)
I'm sure a lot of people here will lament that 60 days is way too long to release a fix for most vulnerabilities, and I think that's true. On the other hand, it's probably a "reasonable upper bound" for very complex problems like the TLS session re-negotiation vulnerability, which required coordination between multiple vendors and the IETF in order to fix. In other words, if you think you should get a 60-day head start to fix a security bug, your bug had better be at least as complex as CVE-2009-3555.
OTOH, It's a lot easier to say that if your product that needs fixing is a few magabytes of browser (and your customers do most of their complex processing on the server) than if your product that needs fixing is gigabytes of operating system with thousands of products that are much more complex than a browser running on top of it and that may be affected by the fix.
Re:60 days = upper bound, not average (Score:5, Insightful)
One. You are correct. Google is almost certainly taking advantage of the fact that browsers are substantially less complex(and people are comparatively tolerant of little rendering glitches, unless they scotch the whole page or "people" happen to be graphic designers...). It is a cynical; but very logical, tactic to talk most about the virtues you can cultivate most easily(though, conceivably, 60 days might actually be a much tighter limit for some of their server stuff, I don't know how hairy that can get).
Two. If your product is too large, and too tightly coupled, to turn around a fix in two months you had better have a very compelling reason. Arguably, Microsoft's relatively tight coupling of an enormous number of pieces has been very good business; but not very good design. In the short term, Google's implicit dig is rather cynical. In the longer term, though, they are really scoring a point in a battle of architectural philosophies. Microsoft probably actually handles size, complexity, and tight inter-relation better than most(they'd be dead if they didn't); but the problems that it causes them are basically their fault. They made that mess, they deliberately coupled stuff for economic reasons that could have been decoupled for engineering ones....
Re: (Score:2)
I disagree.
It's not like one guy wrote Windows - there are teams and teams of engineers. Microsoft employs thousands of them - there were about 1000 who wrote Windows 7, for example. Each part of the operating system is divided up into manageable components. Each of those components is divided into manageable parts, and each of those parts is divided into manageable functions, on down until you have a handful of engineers responsible for one small section of the OS.
When a vulnerability is disclosed, the
Re: (Score:2)
They should employ 100,000 coders, that way exploits will get fixed minutes after they're found!
Re: (Score:2)
As every IT manager knows, the amount of time it takes to produce some code is directly proportional to the number of people working on it!
They should employ 100,000 coders, that way exploits will get fixed minutes after they're found!
In that case, you can do even better: employ only 1/100,000 of a coder, and exploits will be fixed in nanoseconds! (Or wait, did you mean inversely proportional?)
Re: (Score:2)
Re: (Score:2)
(Not just "behaving to spec" but "behaving exactly the same as it did yesterday")
I'd say that that has a great deal to do with loose or tight coupling... Your point is valid in that Microsoft is not, personally, responsible for all the tight coupling in the Wintel ecosystem. They do do some of it themselves, but their larger contribution is probably in aiding and abetting the producers of various large, expensive software stacks in doing tight coupling of their own.
This has been good business, Microsoft's customers generally like the backwards compatibility, because it saves them fro
Re:60 days = upper bound, not average (Score:5, Insightful)
If your bug is so big that you can't fix it in 60 days, then you need to drop the secrecy anyway so that the rest of the world can help you fix it (or work around the fact that you can't).
Remember that these bugs are things that shouldn't exist in the first place.
Re: (Score:2, Insightful)
Re: (Score:2)
but, apple releases update to OSX that breaks photoshop, and they have fixed the bug in xcode(the approved way of software on OSX), then shouldn't adobe just update their xcode/OSX, press the "re package, patch" button, and ship the update? why should MS be concerned about 3rd party apps? does MS software still work, or receive patches? good problem solved.
Re: (Score:2)
That's easy to answer. Gates doesn't have a RDF so people expect Windows not to break 3rd party apps. Apple fans will put up with anything.
Re: (Score:1)
No... Windows dwarfs Linux in size, plain and simple. Linux has become bloated over the years, but not as bloated as Win32.
And windows has a ton of massive APIs, Libraries and platform SDKs, each really quit emassive, and all a 'core part' of the windows OS.
Gigabytes, probably over 5gb is quite likely I would say, if you include resource objects that are part of sources in Win32 environment.
Even in Windows '95 days, Windows was always considered bloated, and Linux was lean and mean.
If you take j
Re: (Score:2)
Windows is an OS kernel, a very large set of system libraries, plus a few hundred applications (everything from Calculator to Internet Explorer). Linux source is just the kernel. If you want a real comparison, compare a Linux distro (say, Ubuntu) to Windows. Wikipedia already did it for you [wikipedia.org].
XP is 40M LOC, its contemporary Debian 3.0 is 104M LOC. I don't have a source for the size of the Windows kernel source code, but Windows 7's compiled kernel is ~5.4MB; Linux's compiled (core) kernel tends to run abo
Re: (Score:2)
Microsoft deprecates old APIs? When did that start? I thought some of their vulnerabilities were due to maintaining crufty old code for various companies' internal apps.
Re: (Score:1)
We should probably distinguish between simple coding mistakes and fundamental security flaws in standards-defined protocols.
Just because some flaws are complex enough that it may justifiably and reasonably take more than 2 weeks to deliver a patch does not mean there is a free pass to be laid back and wait that long to patch all flaws.
It's not justifiable to wait 30 days to fix a one-line coding mistake that allowed a buffer overflow or underflow condition.
Re: (Score:2)
It's a lot better than the 720 day upper bound* that Microsoft uses, though.
* I don't actually think they have an "upper bound" that starts from when they discover the vulnerability. The clock for the upper bound doesn't seem to start until the vulnerability is publicly disclosed. I'm sure the only reason that 720 day old high-severity vulnerability was fixed was because some Microsoft was bored that day.
Re: (Score:1)
Putting vulnerabilities in escrow? (Score:5, Interesting)
Re: (Score:2)
This is an excellent idea.
Re: (Score:2)
Yes, and it's one I suggested the last time around with this subject. Irrevokeable Authenticated Delayed Publication [slashdot.org]
Re: (Score:2)
Re: (Score:2)
.. the logical next step for the industry would be to put security vulnerability reports in escrow, with an automated time release. ..
This is an amazingly simple solution. I'm surprised nobody has implemented this already.
Re: (Score:2)
Unfortunately, the major vendors will be violently against such a thing, so it's something the researchers themselves will have to implement. In doing so they'll probably lose friendly relations with major vendors - and by "lose friendly relations" I mean be slandered constantly.
I think it would be worth it though.
Re: (Score:2)
It's a really good idea.
Part of the idea would have to be having a REPUTABLE escrow service disinterested in publicity - a service that can work with both the vendor and the security researcher and balance the competing interests.
Every security researcher wants to maximize the severity rating of the bug, an instantaneous commitment to a fix timeline, and an absurdly tight deadline (expects vendor to drop everything to analyze the bug, fix it perfectly on the first try, and release immediately). Responsible
Re: (Score:2)
I think it's a terrible idea. It's like pre-planning your future investments and locking them in. What if you did that just before our latest recession? Putting your fate in a dead hand is never a good idea.
60 days is not 5 (Score:3, Insightful)
So google is defending the actions of an engineer who posted attack code on a Windows vulnerability 5 days after he reported it to Microsoft by saying that 60 days is more than enough time to fix a critical vulnerability...how exactly does that reasoning work?
Re: (Score:2)
Re:60 days is not 5 (Score:4, Insightful)
Re: (Score:2)
Yes, and us full disclosure supporters in the security community have been literally saying that for years. Good to see that some of the bigger players finally wake up.
Re: (Score:2)
So what is the business case for a Google researcher to be looking for vulnerabilities in Windows code other than for competitive reasons? Does Google guarantee that there are zero vulnerabilities in all of their own code? If not, why isn't he still looking at Google's code?
Re: (Score:1, Flamebait)
You forgot the part where the hypothetical researcher has privately reported numerous critical vulnerabilities to the hypothetical company and waited months or years for fixes. You also missed the researcher providing two different fixes for this particular vulnerability in his disclosure announcement. But hey, why make a fair comparison when you can resort to sensationalist slander?
Re: (Score:2)
Re:60 days is not 5 (Score:5, Informative)
Read the actual reporting on what happened. Tavis gave MS 60-days, but they refused to commit to any timeline. So, he went ahead and disclosed immediately, along with a fix for affected systems.
It's also important to understand that Tavis has been reporting critical vulnerabilities to MS for years--and in some cases waited over a year for them to push a fix. This time he saw something trivial that should be fixed immediately and he put their feet to the fire. Oddly enough, they did push out their own fix in under 60 days after the vulnerability was made public. So you don't have to agree with his methods, but you should at least frame the situation correctly.
Please read what actually happened (Score:5, Insightful)
Microsoft *never* refused to commit to a timeline. They didn't commit to a timeline within 3 days, so 4 days after reporting the bug mr.
Ormandy went public. If he truly believed that 60days would be reasonable he could just have informed MS that he would go public exactly 60 days later. But no, Ormandy just needed an excuse to go public and show the world how much smarter than Microsoft he is.
60 days may seem long, but it is actually very close to the current average for the largest software providers - not just Microsoft. Mozilla patches much faster but we have also seen several incidents where a Mozilla patch broke the browser and/or was ineffective. Consider the fallout if suddenly all French Windows XPs/Vista were unable to boot. MS needs to regression test each and every combination. Remember what happened when malware caused Windows XPs to not boot because and old DLL had been patched and addresses assumed by the malware had shifted?
Re: (Score:2)
Microsoft *never* refused to commit to a timeline. They didn't commit to a timeline within 3 days, so 4 days after reporting the bug mr.
Ormandy went public. If he truly believed that 60days would be reasonable he could just have informed MS that he would go public exactly 60 days later...
That timeline doesnt look good. He should have waiting five days for a commitment, as recommended by the RFPolicy [wikipedia.org].
Re: (Score:2)
Well, since he posted 5 days later, it sounds like that's exactly what he did.
Re: (Score:2)
Actually, it says "five working days." Meaning you give them five non-holiday weekdays, and then disclose it on the sixth weekday.
The sixth weekday in this case would have been 9 days after the author originally reported the bug; because it was a Saturday, you'd have two weekends before the sixth weekday, during which you'd report it.
Black hats aren't limited by holidaysi (Score:2)
Meaning you give them five non-holiday weekdays
The black hats aren't limited by weekends and holidays. Once the black hats start exploiting a vulnerability on the Wednesday night before US Thanksgiving, the start of a four-day weekend, then what should a legitimate security professional do?
Re: (Score:2)
adtifyj was the one who suggested Tavis Ormandy should have waited "five days" according to RFPolicy. I was pointing out to Bigjeff5 that RFPolicy actually says "five working days." If you want to argue the merits of RFPolicy, I suggesting replying to adtifyj's post,
Re: (Score:3, Insightful)
bah.
It's not the security researchers responsibility to cover Microsoft's ass. Anything he gives them is a gift not a god damned right. If you want to blame someone for all the exploits blame the dumb ass that decided to couple html help shit with everything and allow it to execute binaries. Just fucking stupid.
Sounds to me like Microsoft sat on it's ass for three days and then told him /we will get back to you on Friday/ which would piss me the fuck off too. You can't fucking figure out if you can commit t
Re: (Score:2)
MS needs to regression test each and every combination.
Frankly, this argument just proves how bad their testing method is.
At my job (and at Google's company too), we are using agile methodologies, and especially TDD (and also more complete regression tests).
TDD implies that you write the tests before writing code, and this allows to quickly test any kind of components automatically.
Regression tests are automated too, in order to early locate any kind of problem, and we are doing it with virtual machines, to avoid installing tons of computers.
From my point of vi
Re: (Score:2)
If your application has problems, the user's computer continues working.
If a Microsoft
Re: (Score:2)
And sometimes they don't take into account certain potential problems, such as malware preventing one file from updating, making the system Bluescreen at boot.
You are mixing 2 events in your memory:
1) blue-screen due to a malware which modified a driver.
2) continuous reboots when updating an antivirus.
These have nothing to do with Microsoft !
In these cases, I'm siding with Microsoft: it's not their responsability to be compatible with third-party software (malware and antivirus) !
Re: (Score:2)
You're correct. I was referring to the first incident, and was under the impression that the MS update replaced (or failed to replace) the driver file, but apparently it wasn't supposed to.
For those who don't know what I'm talking about, KB977165 [microsoft.com] updated the kernel, and would cause computer infected by the Alureon rootkit to BSOD on reboot [technet.com].
Re: (Score:2)
People keep saying that Microsoft needs to regression test each language and version of their operating system. That is not true. A well-designed program operates independently from it's translation files. All that is necessary in a well-designed program is to catch all instances of "translate ('english string')" and create a library out of it. In most software packages and even operating systems you can drop in and out of different languages even on a per-user basis.
Also, other programs that are part of th
Re:Please read what actually happened (Score:5, Interesting)
So publically disclose after 60 days like you said you would. Not after 5 days, like you said you wouldn't.
"Yeah man, I knocked him out and stole his wallet. In my defense, he frequently undertips."
Google is not responsive to bug reports (Score:1)
This bug is a regressions that completely prevents usage of local copy of java api documentation.
Recently, I have found another bug in google "Documents": the AltGr key does not work in new documents. On a french keyboard, I can not type any more the characters {, [, |, \, ^, @,
The workaround is to duplicate an old document.
I think they are drowning in an avalanche of bugs.
Correcting security
Re:Please read what actually happened (Score:4, Insightful)
Re: (Score:1)
Resonable, sure. But the point is, if Tavis offered MS a lack of disclosure for a guaranteed timeline for a fix and MS's response is anything but an "I accept", Tavis has no responsibility to keep the offer standing anymore than MS is obligated to keep the price on a copy of Windows 7 on Friday the as Tuesday just because on Wednesday yo
Re: (Score:2, Troll)
If you give someone a 60 day deadline, you stick to it. You don't throw a hissy fit and put far more computers at risk because they didn't behave exactly as you want.
Yes the code was known and being exploited but he made the exploit far more widespread (just look at the explosion of malware that abused the bug that appeared days after he published it).
Sorry,
Re: (Score:2)
Re: (Score:2)
What it has to do with Google? (Score:2)
You are correct, Tavis Ormandy claims that he acted on his own. Which is a fair claim, except:
If Tavis Ormandy was employed has a piccolo
Re: (Score:2)
Re: (Score:2)
Because Google is putting out an article/official statement regarding vulnerability fix timelines and public disclosure with his name in the byline. The implication is that they fully support his view on the matter, though the timeline that's being touted as acceptable in the article is not one he stuck to. It's a lot of "do as I say, not as I do."
Jeopardy! (Score:4, Funny)
I can only conclude that this Jeopardy! winner [youtube.com] now works for Google.
I don't get it (Score:3, Insightful)
Re: (Score:2)
You need to read it backwards!
0-day (Score:1)
Just release the discoveries and let the sane companies adapt and start testing their software properly before shipment. Pussyfooting around companies that has no other interest in security other than PR is never going to accomplish anything.
Known google account authentication bug (Score:2)
can we dump the tabloidez (Score:2)
Though after the utter utter fiasco of getting the syetms used to facilitate law enfocement requests hacked. on one would have thought that as Clem Atlee said “A period of silence from you would be appreciated” might have been better for Google on security matters.
Re: (Score:2)
Re: (Score:2)