Google Up Ante For Disclosure Rules, Increases Bug Bounty

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."

Comments

Elite

[ceraphis]

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:Elite

[Netshroud]

Well, only the elite will get the reward anyway.

Re:Elite

[cosm]

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:Elite

[Anonymous Coward]

And here I thought I was the only one who speeks HaXoR on the Slashdot
*Ducks*

Re:Elite

[sarathmenon]

And also, it's contradictory to what google did earlier this year. They released a zero day for windows 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:Elite

[mysidia]

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)

Re:Elite

[gmhowell]

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:Elite

[Anonymous Coward]

lolwut.

Re:Elite

[Undead Waffle]

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:

• Placing a disclosure deadline on any serious vulnerability they report, consistent with complexity of the fix. (For example, a design error needs more time to address than a simple memory corruption bug).
• Responding to a missed disclosure deadline or refusal to address the problem by publishing an analysis of the vulnerability, along with any suggested workarounds.
• Setting an aggressive disclosure deadline where there exists evidence that blackhats already have knowledge of a given bug.

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:Elite

[Anonymous Coward]

Google didn't release a Windows vulnerability, someone who happens to work at Google did. He took pains to point out that he was was working independently, but MS and some in the media chose to imply that we was acting on Google's behalf. Don't take my word for it - read Tavis' original post and spender's interesting, if bitter, analysis

Re:Elite

[Your.Master]

It was a potential conflict of interest, 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 policy as really consistent with Tavis' case. Presumably he disclosed because he was "responding to a [...] refusal to address the problem". We know Microsoft did respond to Tavis within the same day on the weekend, but he was unsatisfied with the response and gave full disclosure a few business days later rather than waiting out his deadline. I'd like that part clarified.

Re:Elite

[bloodhawk]

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

[Bigjeff5]

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:Elite

[abigsmurf]

People in China work 80 hour weeks for pathetic wages. Why can't you? There are tasks that need to be done 24/7, not just 40 hours a week!

Re:Elite

[Anonymous Coward]

Not really, it was just that Tavis Ormandy asshole on his own. He is an arrogant idiot and does represent your average googler.

Re:Elite

[taviso]

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:Elite

[asvravi]

They wanted to give approximately 2000 pounds.

Re:Elite

[ClosedSource]

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:Elite

[taviso]

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.

NERDS

[Anonymous Coward]

NERDS!

Re:NERDS

[mcgrew]

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...

[bi$hop]

Dear Google,

I just found a bug in Gmail. We should talk.

Sincerely,
Chinese Hacker

Re:I just found a bug...

[cosm]

Dear Chinese Hacker,

I just found a bug in your government. We should square up.

Sincerely,
Google

Re:I just found a bug...

[Anonymous Coward]

For your sake, 'Chinese Hacker', I hope the "3133.7" value is kept in USD. 3133.7 yen (~$36.26 cents atm) is not much to get excited about when you could be grubbing over CC #s.
-os

Re:I just found a bug...

[bertoelcon]

Its a good thing the Chinese use yuans then. 3133.7 Chinese yuan = 462.5373 US dollars is a little better.

Re:I just found a bug...

[Anonymous Coward]

For your sake, 'Chinese Hacker', I hope the "3133.7" value is kept in USD. 3133.7 yen (~$36.26 cents atm) is not much to get excited about when you could be grubbing over CC #s.
-os

Did you actually read your link?

"3133.7 Japanese yen = 36.2572 US dollars"

The Chinese unit of currency is the yuan, and 3000 yuan is a fairly significant amount of money in China.

Re:I just found a bug...

[Noodlenoggin]

Dear Google, We would like for you to meet us in the 'Square'. All manner of issues have been squashed in the square and I am sure we can some to some kind or arrangement over this issue. Sincerly, Chinese government.

Re:I just found a bug...

[gmhowell]

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.

Re:I just found a bug...

[MoeDumb]

Dear Google, here's a critical vulnerability that needs fixing: selling one's principles for 30 pieces of egg roll.

Re:I just found a bug...

[mcgrew]

Dear Google,

That's not a bug, that's a design flaw^^^^^^^^^^^feature.

Sincerely,
Microsoft

This is good competition

[JoshuaZ]

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.

Re:This is good competition

[AHuxley]

Yes great for a laptop if needed or charity spending if your a trustafarian.
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:This is good competition

[Anonymous Coward]

Can I have some of what you're smoking?

Re:This is good competition

[TubeSteak]

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:This is good competition

[MLS100]

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:This is good competition

[randomsearch]

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:This is good competition

[tehcyder]

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.

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?

Re:This is good competition

[Anonymous Coward]

Yes; who would really cash a $3133.7 cheque from Google?! That's almost as good as one from Knuth. It should come in a frame.

Re:This is good competition

[JoshuaZ]

Missing the point. The bounties aren't what's competitive. What's competitive is the browser market. That they need to keep upping the amount of money they are offering to find problems in their browsers is a function of the competitive browser market.

Re:This is good competition

[cynyr]

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:This is good competition

[ClosedSource]

I suspect a check from Knuth would be at least an order of magnitude harder to get than one from Google.

Re:This is good competition

[Tubal-Cain]

Is it illegal to sell that info in this market?

60 days = upper bound, not average

[Dwonis]

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:60 days = upper bound, not average

[Anonymous Coward]

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

[Anonymous Coward]

Yeah, that's why Microsoft doesn't even respond to responsible disclosures.

Re:60 days = upper bound, not average

[Anonymous Coward]

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

No way, no how, is Windows source code in the gigabytes range. Linux source is ~440MB of which 200MB is drivers and linux has way more native drivers than windows.

Re:60 days = upper bound, not average

[Anonymous Coward]

Well, maybe. Linux would simply break the API and the tens of thousands of programs relying on it.

And as a last resort, the OS you imply -- Microsoft Windows -- would introduce a new API, and deprecate the old one. Or it would run the older programs inside of a VM. Both of these take additional time.

Is one of these approaches better than the other? I don't think so. They both have their advantages and disadvantages. I think it hints at something deeply flawed, when the operating system is so complex -- or monolithic, if you prefer that term -- that one small change can break so many reliant programs.

Re:60 days = upper bound, not average

[fuzzyfuzzyfungus]

I think that your comment can be read on two levels:

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:60 days = upper bound, not average

[Dwonis]

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:60 days = upper bound, not average

[mysidia]

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:60 days = upper bound, not average

[mysidia]

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 just a few of the Win32 APIs, they are easily larger than the Kernel and Xorg combined.

Re:60 days = upper bound, not average

[gmhowell]

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:60 days = upper bound, not average

[Anonymous Coward]

It is not taking them 60 days to make a patch because of product complexity, It is probably taking them only a few hours for the patch, however because of the huge ecosystem around windows they have to do a massive amount of regression testing to ensure they are not breaking anyones products, imagine how much adobe would scream if a security patch broke their products or how about apple for itunes and you can bet the stories wouldn't be "Apple itunes breaks because of poor Apple development practises", it would be "Microsoft intentionally breaks itunes, Apple requests anti monopoly investigation". Most of that time is spent regression testing on every flavour of the product in every language with all the most commonly used applications.

Re:60 days = upper bound, not average

[Anonymous Coward]

I think that your comment can be read on two levels:

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....

You're missing the point. It has nothing to do with loose or tight coupling. It has everything to do with "how big, complex, and mission-critical are the applications that rely on our software behaving exactly the same today as it did yesterday"? (Not just "behaving to spec" but "behaving exactly the same as it did yesterday")

If Chrome pushes a fix that changes scripting a little, triggering a bug in your online banking, most people will grumble quietly but put up with it. And it's a comparatively simple case to predict.

If Windows pushes a fix that changes something in resource management, that triggers a bug in Oracle's Java VM, that means that Goldman Sachs's trading screens cease to function, there's hell to pay. And that is a rather more complex one to predict or debug.

Re:60 days = upper bound, not average

[Bigjeff5]

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:60 days = upper bound, not average

[PsychoticSpoon]

I think that 60 days is a good time frame, because on top of fixing the vulnerability, you also have to convince users to install the patch. Deploying a patch to a large userbase is going to take time, and probably longer than it takes to fix the problem in the first place. That being said, maybe a more responsible approach would be to tell the vendor (and the world) that you're going to publish the vulnerability in X days or 30 days after they release a patch, whichever is longer. Now the vendor has serious motivation to fix the problem and users aren't needlessly being put at risk.

Re:60 days = upper bound, not average

[Bigjeff5]

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 white-hat researchers have already found the exact code that needs fixing, all you have to do is hand it to the group responsible for that section and say "fix it".

If it involves several groups, then the groups have to work together. They had to work together to build the thing, so it's nothing new for them. I really can't imagine any one vulnerability in Windows that would require more than 60 days to fix - that's a long time to deal with this sort of thing, and they have more than enough people to do the job. The only thing that should take that long is something that requires a fundamental change to the core of the OS, and thus requires large scale integration and testing before it can be released. There are very, very, very few issues like that that come along. Even then, there is usually a temporary patch you can come up with until you have time to work the real fix into a service pack or other major update.

Re:60 days = upper bound, not average

[abigsmurf]

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!

Re:60 days = upper bound, not average

[fuzzyfuzzyfungus]

(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 from having to touch their brittle, tightly coupled, systems; and are thus more willing to pay more than they would otherwise be. However, it has left Microsoft in something of an engineering bind. Their own internal product coupling makes their lives more difficult in some respects, and the fact that their best customers are their most change averse makes their lives even more difficult.

Re:60 days = upper bound, not average

[kscguru]

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.

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 about twice that.

Most Windows (and for that matter, Linux) security vulnerabilities are not in the kernel.

Re:60 days = upper bound, not average

[cynyr]

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:60 days = upper bound, not average

[Demonantis]

Not to forget, but windows is a paid for OS. I would expect at least some reasonable support no matter the sophistication then. Google's product is free to the public. How many of those do you know that provide amazing support if any. Their only real responsibility would be image and PR. That is why open source is so great because anyone interested could do the patching themselves instead of relying on the owner of the software to care.

Re:60 days = upper bound, not average

[Simetrical]

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:60 days = upper bound, not average

[ClosedSource]

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:60 days = upper bound, not average

[Tubal-Cain]

How are they measuring Debian? The ~175 MB netinstall disk? Base install + GNOME or KDE? Entire repository?

Then there's all the architectures Debian supports...

Putting vulnerabilities in escrow?

[martin-boundary]

Although it's great to have a company pledge responsible behaviour, the logical next step for the industry would be to put security vulnerability reports in escrow, with an automated time release. This could be as simple as having a CERT server distribute unique encryption keys, with each key being publically disclosed after a countdown from the time it is generated. A security researcher would encrypt each of their reports with such a key (a different one each time) and publish them on the web. Besides reducing the political squabbling between companies, this kind of system would also be great for priority disputes between researchers.

Re:Putting vulnerabilities in escrow?

[Omnifarious]

This is an excellent idea.

Re:Putting vulnerabilities in escrow?

[adtifyj]

.. 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:Putting vulnerabilities in escrow?

[Bigjeff5]

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:Putting vulnerabilities in escrow?

[John Hasler]

This is an excellent idea.

Yes, and it's one I suggested the last time around with this subject. Irrevokeable Authenticated Delayed Publication

Re:Putting vulnerabilities in escrow?

[kscguru]

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 security researchers know that instantaneous is not going to happen, so are willing to wait a few months.

Every vendor wants to minimize the severity rating of a bug, and to push out the fix as long as possible. Delaying is less about saving face and more about saving money: regression testing eventually becomes free (next major release) or at least cheaper (batch several security updates and regression-test simultaneously). I know my employer prefers batching, as does my web browser's vendor (Firefox) - non-critical non-public vulnerabilities get queued and are only fixed with the next critical or public vulnerability or other minor update.

So a vulnerability escrow service needs to mediate these two competing interests. They need to keep pressure on for a deadline, but also need to be reasonable about the deadline in the first place (60 days sounds pretty good) and be flexible enough to move it back if the vendor can demonstrate good-faith efforts to fix that, for reasons outside the vendor's control, won't be able to make the deadline. (Example: the fix breaks Adobe, and they now need another 60-day window to get Adobe to release an update.) For a vendor, every deadline is too short, but for a security researcher, every deadline is too long; only an escrow service with a serious reputation for integrity and serious clout will be able to force both sides to accept a compromise, especially when a security researcher who doesn't like the compromise can so easily throw an adolescent temper-tantrum and go public prematurely.

Re:Putting vulnerabilities in escrow?

[martin-boundary]

Excellent (although I didn't know about your post).

Re:Putting vulnerabilities in escrow?

[ClosedSource]

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.

Re:Putting vulnerabilities in escrow?

[Anonymous Coward]

You could just publish the report on a blog or somewhere (slashdot, digg, pirate bay...). Encrypt it with some algorithm that you know is breakable within some set time frame. Announce the time frame. Send the key to the vendor so they know that the problem exists. No need to get CERT involved.

60 days is not 5

[TouchAndGo]

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:60 days is not 5

[cosm]

Progress comes in little steps. I would say this is better than nothing, baby steps towards holding these megacorps feet to the vulnerability fire is incentivizing the disclosure of the bugs, instead of the cover ups and cease and desist letters who just want their shit fixed for the betterment of the world (or the glory of being 1337).

Re:60 days is not 5

[Hadery]

60 days is the upper bound...

Re:60 days is not 5

[bunratty]

Google is saying that some companies *cough* Microsoft *cough* sit on security bugs for years until they're finally exploited, putting their users at risk. It's only by publicly disclosing the bug that these companies fix the problem.

Re:60 days is not 5

[Anonymous Coward]

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.

Re:60 days is not 5

[Anonymous Coward]

Of course pointing out his fix didn't work would be churlish right? Maybe that fix wasn't so trivial after all.

Re:60 days is not 5

[Anonymous Coward]

For starters I agree about your point. However here is a scenario which isn't brought up as much:
a. Microsoft engineer discloses major security flaw in OSX along with source code and step-by-step guide on how to "replicate" the exploit. The reason is because Apple would not give a timeline for fixing the flaw nor get back to him with a, "hey dude you are fucking genius ... you know that, we have fixed it in the last 72 hours as you requested ... anything else?", message.
b. Microsoft engineer discloses major security flaw in Google Android platform which allows an attack to fully take over the phone. The engineer then produces source code on how to exploit it. The reason is because Google would not give him a timeline for the fix nor any praise of his brilliance. They also failed to provide him with a full schedule of when and how it would be fixed, also refused to get back to him about his request for a conference call with the software development team. The dicks.

Now what would be the reaction on Slashdot? Somehow I have a hard time believing that people would be taking the same stance, instead they would view this as Microsoft attacking Google/Apple and how they have compromised the security of average user of OSX/Android. Once exploits hit the internet and started to spread, people would talk about suing Microsoft for being a corporate version of a douche-bag.

I know ... I know ... its apples and oranges ... Microsoft is the Anti-Christ and Google/Apple are Jesus/Buddha respectively.

Re:60 days is not 5

[Tom]

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:60 days is not 5

[Anonymous Coward]

It's also the upper bound he gave. Then he turned around and disclosed after 5 days instead.

Re:60 days is not 5

[n0-0p]

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:60 days is not 5

[abigsmurf]

He did frame it correctly. He gave them 60 days to fix it. Not "60 days to fix it plus you must stroke my ego sufficiently and quickly enough".

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, Travis is a scumbag lacking in morals who only cared about grabbing headlines.

Re:60 days is not 5

[hkmwbz]

What does this have to do with an individual doing something on his own behalf, not Google's? How is Google defending anything?

Re:60 days is not 5

[hkmwbz]

What does this have to do with Google, exactly?

Re:60 days is not 5

[abigsmurf]

Perhaps try RTFS? The article says/speculates that this is in response to what we're discussing.

Re:60 days is not 5

[Anonymous Coward]

It's also important to note that Tavis used to be employed by Google, and still does consultancy work for them. It's not like Google's sticking up for an independent third party here. They're sticking up for someone who is very closely linked with their security work.

Re:60 days is not 5

[Anonymous Coward]

Umm. Don't believe everything you read on the internet (or more directly: someone is spinning this; or even more directly: someone is lying).

You should ask Tavis himself for the truth.

Re:60 days is not 5

[Anonymous Coward]

If you read the actually statement you would find they have many exceptions to the 60 day rule. The one which would apply to the microsoft case is "Setting an aggressive disclosure deadline where there exists evidence that blackhats already have knowledge of a given bug."

Re:60 days is not 5

[Anonymous Coward]

This reminds me of a scene from the 007 film GoldenEye:

Alec Trevelyan: Good luck with the floor James. I've set the timers for six minutes, the same six minutes you gave me. It was the least I could do for a "friend".
[snickers]
Natalya Simonova: What does he mean?
James Bond: We've got three minutes.

Re:60 days is not 5

[TouchAndGo]

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."

Re:60 days is not 5

[ClosedSource]

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?

Jeopardy!

[jrivar59]

I can only conclude that this Jeopardy! winner now works for Google.

Google to Microsoft:

[mentil]

We've upped our ante; up yours!

Re:Google to Microsoft:

[AHuxley]

$3640 ought to be enough for any report.

Re:Google to Microsoft:

[gmuslera]

Even if Microsoft offer to pay just $3.64 per bug report in IE they will go bankrupt in a week....Ok, maybe 2 weeks, just because the source is not available.

Please read what actually happened

[benjymouse]

1. Tavis Ormandy reported the bug to Microsoft on a Saturday and wanted Microsoft to commit to a 60 day timeframe.
2. On Tuesday (a patch tuesday, mind you) Microsoft told mr. Ormandy that they would be able to present a plan the upcoming Friday - i.e. 3 days later and 6 days after the bug had been reported.
3. Wednesday mr. Ormandy went public.

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:Please read what actually happened

[Anonymous Coward]

You've obviously never reported a security bug to MS before. This is their standard story, but it always plays out into months of stalling and excuses. And if you disagree, please provide examples of "responsibly" disclosed vulnerabilities that Microsoft has patched in under 60-days from the initial report.

Re:Please read what actually happened

[adtifyj]

1. Tavis Ormandy reported the bug to Microsoft on a Saturday and wanted Microsoft to commit to a 60 day timeframe.
2. On Tuesday (a patch tuesday, mind you) Microsoft told mr. Ormandy that they would be able to present a plan the upcoming Friday - i.e. 3 days later and 6 days after the bug had been reported.
3. Wednesday mr. Ormandy went public.

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.

Re:Please read what actually happened

[Anonymous Coward]

I certainly have reported bugs to MS before and have generally foudn them to be "reasonably" responsive in most cases. Nothing in the Ormandy case suggested MS were in any way shape or form unresponsive. Ormandy was just a complete prick.

PErsonally I am disappointed in googles lack of response to that incident. Google should be held to the same standard and be given no more than 5 days from initial reporting of any security hole to full public disclosure and means to exploit the hole.

Re:Please read what actually happened

[Your.Master]

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."

Re:Please read what actually happened

[Anonymous Coward]

If you can't make an honest case, please don't waste my time. Tavis gave MS a timeline and they refused to commit. And even while shilling for MS you're incapable of providing a single example of them turning around a vulnerability fix in under 60 days without the pressure of public disclosure.

Re:Please read what actually happened

[bloodhawk]

Tavis gave MS a timeline and they said can't commit right this instant but we will get back to you by friday (pretty resonable considering it was a patch tuesday for them). Tavis then publishes on wednesday like a total douchebag. There is no way you can twist this that makes Tavis look like anything but a douche. The only possible way he could have looked less of a prick is if he waited till saturday and had no further response he could have published it, even then though it goes against what he claims is responsible disclosure.

Re:Please read what actually happened

[Bigjeff5]

Well, since he posted 5 days later, it sounds like that's exactly what he did.

Re:Please read what actually happened

[10101001 10101001]

Tavis gave MS a timeline and they said can't commit right this instant but we will get back to you by friday (pretty resonable considering it was a patch tuesday for them).

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 you said you would "get back to them on friday".

Tavis then publishes on wednesday like a total douchebag. There is no way you can twist this that makes Tavis look like anything but a douche.

In the same way all contractual transactions tend to make people look like douchebags because in the end they try to take very real aspects of reality and abstract them into simple language; the fact that any sort of non-agreement on terms can result in an offer being dropped or significantly changed because one party chooses it is a fact of negotiation both sides have to understand before any sort of contractual engagement.

The only possible way he could have looked less of a prick is if he waited till saturday and had no further response he could have published it, even then though it goes against what he claims is responsible disclosure.

Yea, I'm going to have to go with "It's not Tavis Ormandy's job or responsibility to live up to a timetable MS creates for when to negotiate when Tavis Ormandy is the one trying to generously inform MS about a vulnerability before, quite rightly and properly, disclosing such information to the general public."

MS isn't a person. Whatever claims of social responsibility one can extend from offering help to a person resulting in an obligation to offer more effort than originally intended doesn't extend to companies. The people or entity most hurt by full disclosure in this discussion is MS because, in the end, it makes publicly visible the vulnerability in a Microsoft product and risks them future sales. Yes, this may pragmatically result in the short term in more people being hurt. In the end, the fault likes in Microsoft producing the buggy code and those who would exploit that code, not the disclosure of the existence of that buggy code (aka don't shoot the messenger).

Microsoft is not alone in this, btw. Google, Adobe, Apple, etc are just as responsible for the buggy code they create and/or include from other sources but fail to sufficient test/verify. This holds true for any person or organization that releases software, hardware, or whatever. The funny aspect of it is, the best defense that Microsoft can argue is that everyone has bugs, but again pragmatically the bugs in Microsoft code has a disproportion effect on people so even if it were true that Microsoft code was on average as buggy as other code, there's still as much reason to avoid Microsoft software; in the pragmatic end, the objective isn't to avoid Microsoft code completely but for all players to have a percentage of the market based in part on the effect of security vulnerabilities. Hence, the publicity of such vulnerabilities instead of being able to bury each vulnerability is in the long term pragmatic interest of people.

This, open information leading towards perfect information, is at the very core of the optimizing effect of the free market as it relates to the marketplace of software and ideas.

Re:Please read what actually happened

[xous]

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 to having this fixed within a 60 day time-line in three days? And to all the dumb fucks saying he should have released after the sixty days like he said: He wanted a sixty day commit in order to withhold the advisory. He didn't get one so he promised nothing.

Re:Please read what actually happened

[Anonymous Coward]

Fact is, the dude threw a fit because MS would only respond to him on friday. He's a fucking faggot and a huge one at that. He should've sticked to his 60-day timeline, instead he just wanted fame.

Re:Please read what actually happened

[eulernet]

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 view:
- prioritizing the bug will probably take 2-3 days (prioritizing means that the bug will determine when the bug will be fixed).
- fixing the problem will probably take one week to several programmers (using pair-commiting)
- testing all the versions will probably take 2 weeks to a group of people (and this process can be distributed between different teams)

Presumably, this process is continuous, so this means that you have teams already working 100% of their time on fixing the bugs, so fixing the problems doesn't need to start building teams, etc...

If the management process is longer than 2 months, it means that Microsoft has serious problems with their methodology.

And if Microsoft doesn't use such automation to test the stability of their releases, then shame on them !

Re:Please read what actually happened

[VGPowerlord]

Well, since he posted 5 days later, it sounds like that's exactly what he did.

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.

Re:Please read what actually happened

[VGPowerlord]

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.

If your application has problems, the user's computer continues working.

If a Microsoft Windows update fails, the user's computer... well, have you ever had Windows die on boot?

Not surprisingly, this means that Microsoft's tests for Windows are not solely software tests.

As I understand it, they have entire labs to test Windows on different hardware. Which need to be re-tested at each patch due to obscure driver or hardware bugs.

And they sometimes still miss some. 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.

Re:Please read what actually happened

[guruevi]

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 the Windows suite (Internet Explorer, Windows Media) should be able to be patched, updated, replaced without the operating system hanging. They're freaking applications that shouldn't need administrator privileges to run so they shouldn't be able to touch the vital parts of the system. Unless you're fixing/replacing vital parts of the system (certain vital linked libraries like glibc on Linux or user32.dll on Windows) you don't really have to do a whole lot of testing - the application should run independently from the rest of the system. Why do you think Linux users can switch between Gnome and KDE? Or choose not to use SELinux?

Of course this is Microsoft we're talking about who has integrated both Windows Media and Internet Explorer into the kernel of the system (or at least that's what they claimed in court). If they would've just kept with a fully functional Windows version for a fixed price and not gone with Starter, Home Basic, Home Premium, Professional, Ultimate, Enterprise, Starter N, Home Basic N, Home Premium N, Professional N, Ultimate N, Enterprise N, Starter K, Home Basic K, Home Premium K, Professional K, Ultimate K, Enterprise K, Starter KN, Home Basic KN, Home Premium KN, Professional KN, Ultimate KN, Enterprise KN, Starter E, Home Basic E, Home Premium E, Professional E, Ultimate E, Enterprise E there would've been a whole lot less testing needed. Apple does it right - Mac OS X and Mac OS X Server. Windows has more versions from the same vendor than there are mainstream Linux distro's. And then there are vendors that modify Windows to distribute for their own appliances and we haven't talked about Windows Server yet.

Re:Please read what actually happened

[eulernet]

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:Please read what actually happened

[bwalzer]

I may be insensitive but this strikes me as quite funny. Someone reports a bug. Since the vender is famous for heel dragging the submitter gives them the chance to commit to a reasonable time frame.

Submitter: Here is a significant security vulnerability that you guys have missed for a zillion years. ... 3 days of silence ...

Vender: Hey! Thanks ever so much for your bug report! We are working really really hard to come up with a response on that 60 day thing! Just give us another 3 days and then we might actually commit! You didn't have anything else better to do with your life anyway right? Have a super day!

Submitter: You seem to be confused here. I do not have to take your crap. Bug disclosed. have a super day!

Vender: Oh no! You never warned us that you were not willing to let us screw around with you indefinitely! How terribly irresponsible of you!

Sounds like a happy ending to me...

Re:Please read what actually happened

[VGPowerlord]

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.

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 updated the kernel, and would cause computer infected by the Alureon rootkit to BSOD on reboot.

Re:Please read what actually happened

[Anonymous Coward]

Microsoft *never* refused to commit to a timeline.

Are you on the supreme court?? Do they have to say "we refuse to speak" before you realize they aren't working with you? We'll get back to you next week, or latter, maybe, if it's convenient for us, isn't an answer. And if you want to argue that wasn't what MS said, the GP pointed out:

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.

So who are you to judge, because we know his experience.

I don't get it

[T Murphy]

What does this "eleeto" mean? Is it some sort of slang term or something?

Re:I don't get it

[moonbender]

You need to read it backwards!

Re:I don't get it

[Archangel Michael]

Don't you mean upside down??? ;)

Google is not responsive to bug reports

[e70838]

I have reported a bug to google chrome (issue 45970) more than one month ago. They are not responsive at all.
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 holes is probably important, but fixing major regressions on basic functionalities should not be neglected.

Re:Google is not responsive to bug reports

[e70838]

My apologizes.
In fact, google is very responsive when bugs are reported on slashdot.
Thank you very much.

Sleep? Weekends?

[Anonymous Coward]

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 of account access information in your inbox - valuable information that could be worth more money elsewhere if you're in a responsible position.

This market doesn't take weekends. It doesn't take coffee breaks. It doesn't go home at night. The Windows Vulnerability market is a Bazaar open 24/7, where admin access to any Windows machine can be had by any traveller with enough ready cash.

Well done.

[Sockatume]

That's the joke.

0-day

[miffo.swe]

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

[bjourne]

Google should fix their own account authentication system before they throw the first stone. Internet is full of reports like these about the problem:

• http://talk.maemo.org/showthread.php?t=48382
• http://blogoscoped.com/archive/2009-05-19-n84.html
• http://derickng.com/posts/103-google-account-hijacked-or-just-a-bug
• http://www.google.sh/support/forum/p/youtube/thread?tid=4426cc7a854b727d&hl=en
• http://answers.yahoo.com/question/index?qid=20100321162016AAZnwCC
• http://www.google.pl/support/forum/p/gmail/thread?tid=13d02f7a7404e5f6&hl=en
• http://www.google.com/support/forum/p/youtube/thread?tid=4426cc7a854b727d&hl=en
• http://www.davidnaylor.co.uk/my-google-account-is-showing-someone-elses-adsense-account.html

Hopefully google finds the bug before someone publishes an exploit for it and puts everyones gmail accounts at risk.

can we dump the tabloidez

[mjwalshe]

when submitting stories, its hardly "lashing out" is it?

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.

Promises Ring Hollow With Old Issues

[Anonymous Coward]

Google should go about fixing up some of their old bugs before attempting to make new promises about security.

http://code.google.com/p/chromium/issues/detail?id=3543 has been around for years and exposes minor to moderate security issues. It has been a Priority 1 bug for quite awhile and they just keep releasing new Chrome versions without any update on this bug.

In related news...

[davidwr]

According to top-sekret SVR files, the ever-dwindling royalty checks for the elite Soviet spies Boris and Natasha were 0.31337 rubles by the time of the The Adventures of Rocky & Bullwinkle movie, far less than that of our heroes.

The Biggest Loser

[tepples]

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.

Black hats aren't limited by holidaysi

[tepples]

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:Black hats aren't limited by holidaysi

[VGPowerlord]

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?

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, not mine.

What it has to do with Google?

[benjymouse]

You are correct, Tavis Ormandy claims that he acted on his own. Which is a fair claim, except:

1. Tavis Ormandy is employed by Google as a security researcher - so this is what he does for Google
2. Tavis Ormandy used Google time and Google resources when researching this vulnerability - whether this was his 20% project or not.
3. Tavis Ormandy communicated with fellow Google security researchers using their time and resources. He even thanked them publicly in his disclosure.

If Tavis Ormandy was employed has a piccolo or cook maybe Google could get away with disassociating them from his behavior. But not when he does exactly what they pay him to do.

Comment removed

[account_deleted]

Comment removed based on user account deletion