Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Up Ante For Disclosure Rules, Increases Bug Bounty

kdawson posted more than 4 years ago | from the responsibility-cuts-both-ways dept.

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

Sorry! There are no comments related to the filter you selected.

Elite (5, Funny)

ceraphis (1611217) | more than 4 years ago | (#32973832)

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 (1)

Netshroud (1856624) | more than 4 years ago | (#32973844)

Well, only the elite will get the reward anyway.

Re:Elite (0, Offtopic)

cosm (1072588) | more than 4 years ago | (#32973848)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974164)

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

Re:Elite (2, Insightful)

sarathmenon (751376) | more than 4 years ago | (#32974208)

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:Elite (1)

gmhowell (26755) | more than 4 years ago | (#32974380)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974392)

lolwut.

Re:Elite (1)

abigsmurf (919188) | more than 4 years ago | (#32974830)

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!

Sleep? Weekends? (2, Interesting)

Anonymous Coward | more than 4 years ago | (#32975022)

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.

Re:Elite (4, Informative)

Undead Waffle (1447615) | more than 4 years ago | (#32974406)

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 (2, Insightful)

bloodhawk (813939) | more than 4 years ago | (#32974712)

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 (1, Informative)

Anonymous Coward | more than 4 years ago | (#32974416)

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 [seclists.org] and spender's interesting, if bitter, analysis [seclists.org]

Re:Elite (0, Troll)

Your.Master (1088569) | more than 4 years ago | (#32974520)

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 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 (4, Interesting)

Bigjeff5 (1143585) | more than 4 years ago | (#32974744)

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 (0)

Anonymous Coward | more than 4 years ago | (#32975206)

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 (1)

mysidia (191772) | more than 4 years ago | (#32974220)

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. (1)

Sockatume (732728) | more than 4 years ago | (#32975468)

That's the joke.

NERDS (3, Funny)

Anonymous Coward | more than 4 years ago | (#32973854)

NERDS!

Re:NERDS (1)

mcgrew (92797) | more than 4 years ago | (#32977304)

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... (5, Funny)

bi$hop (878253) | more than 4 years ago | (#32973858)

Dear Google,

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

Sincerely,
Chinese Hacker

Re:I just found a bug... (5, Insightful)

cosm (1072588) | more than 4 years ago | (#32973998)

Dear Chinese Hacker,

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

Sincerely,
Google

Re:I just found a bug... (2)

Noodlenoggin (1295699) | more than 4 years ago | (#32974374)

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... (1)

MoeDumb (1108389) | more than 4 years ago | (#32975706)

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... (0)

Anonymous Coward | more than 4 years ago | (#32974052)

For your sake, 'Chinese Hacker', I hope the "3133.7" value is kept in USD. 3133.7 [google.com] 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... (1)

bertoelcon (1557907) | more than 4 years ago | (#32974118)

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... (0)

Anonymous Coward | more than 4 years ago | (#32974122)

For your sake, 'Chinese Hacker', I hope the "3133.7" value is kept in USD. 3133.7 [google.com] 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... (2, Funny)

gmhowell (26755) | more than 4 years ago | (#32974388)

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.

This is good competition (4, Insightful)

JoshuaZ (1134087) | more than 4 years ago | (#32973864)

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 (1)

AHuxley (892839) | more than 4 years ago | (#32973934)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974030)

Can I have some of what you're smoking?

Re:This is good competition (1)

TubeSteak (669689) | more than 4 years ago | (#32974346)

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 (0)

Anonymous Coward | more than 4 years ago | (#32975750)

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

Re:This is good competition (1)

JoshuaZ (1134087) | more than 4 years ago | (#32976106)

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 (0, Troll)

MLS100 (1073958) | more than 4 years ago | (#32974440)

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 (1)

randomsearch (1207102) | more than 4 years ago | (#32974980)

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 (1)

tehcyder (746570) | more than 4 years ago | (#32975518)

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?

60 days = upper bound, not average (4, Insightful)

Dwonis (52652) | more than 4 years ago | (#32973868)

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 (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32973910)

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 (0)

Anonymous Coward | more than 4 years ago | (#32973922)

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

Re:60 days = upper bound, not average (0)

Anonymous Coward | more than 4 years ago | (#32973994)

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 (1)

mysidia (191772) | more than 4 years ago | (#32974368)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974038)

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 (1)

gmhowell (26755) | more than 4 years ago | (#32974400)

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 (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#32974042)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974684)

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 (1)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#32976334)

(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 (1)

Bigjeff5 (1143585) | more than 4 years ago | (#32974796)

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 (1)

abigsmurf (919188) | more than 4 years ago | (#32974844)

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 (4, Insightful)

Dwonis (52652) | more than 4 years ago | (#32974044)

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 (2, Insightful)

Anonymous Coward | more than 4 years ago | (#32974512)

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 (1)

mysidia (191772) | more than 4 years ago | (#32974332)

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 (1)

Bigjeff5 (1143585) | more than 4 years ago | (#32974768)

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 (1)

PsychoticSpoon (1580137) | more than 4 years ago | (#32974776)

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.

Putting vulnerabilities in escrow? (4, Interesting)

martin-boundary (547041) | more than 4 years ago | (#32973942)

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? (1)

Omnifarious (11933) | more than 4 years ago | (#32974292)

This is an excellent idea.

Re:Putting vulnerabilities in escrow? (1)

adtifyj (868717) | more than 4 years ago | (#32974386)

.. 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? (1)

Bigjeff5 (1143585) | more than 4 years ago | (#32974808)

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.

60 days is not 5 (2, Insightful)

TouchAndGo (1799300) | more than 4 years ago | (#32973962)

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 (1)

cosm (1072588) | more than 4 years ago | (#32974026)

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 (1)

Hadery (1858536) | more than 4 years ago | (#32974040)

60 days is the upper bound...

Re:60 days is not 5 (0)

Anonymous Coward | more than 4 years ago | (#32974570)

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

Re:60 days is not 5 (3, Insightful)

bunratty (545641) | more than 4 years ago | (#32974050)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974510)

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 (0, Flamebait)

n0-0p (325773) | more than 4 years ago | (#32974680)

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 (1)

Tom (822) | more than 4 years ago | (#32974514)

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 (5, Informative)

Anonymous Coward | more than 4 years ago | (#32974066)

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 (4, Insightful)

benjymouse (756774) | more than 4 years ago | (#32974288)

  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 (0)

Anonymous Coward | more than 4 years ago | (#32974398)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974476)

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 (0)

Anonymous Coward | more than 4 years ago | (#32974632)

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 (3, Insightful)

bloodhawk (813939) | more than 4 years ago | (#32974694)

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 (1)

10101001 10101001 (732688) | more than 4 years ago | (#32975004)

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.

Google is not responsive to bug reports (1)

e70838 (976799) | more than 4 years ago | (#32974842)

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:Please read what actually happened (4, Interesting)

Your.Master (1088569) | more than 4 years ago | (#32974578)

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 (1)

adtifyj (868717) | more than 4 years ago | (#32974420)

  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 [wikipedia.org] .

Re:Please read what actually happened (1)

Bigjeff5 (1143585) | more than 4 years ago | (#32974822)

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

Re:Please read what actually happened (1)

VGPowerlord (621254) | more than 4 years ago | (#32976472)

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 (2, Insightful)

xous (1009057) | more than 4 years ago | (#32975686)

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 (0)

Anonymous Coward | more than 4 years ago | (#32975976)

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 (1)

eulernet (1132389) | more than 4 years ago | (#32976250)

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 (1)

VGPowerlord (621254) | more than 4 years ago | (#32976542)

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 (1)

guruevi (827432) | more than 4 years ago | (#32977338)

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

Anonymous Coward | more than 4 years ago | (#32974508)

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 (1, Troll)

abigsmurf (919188) | more than 4 years ago | (#32974810)

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 (1)

hkmwbz (531650) | more than 4 years ago | (#32975108)

What does this have to do with Google, exactly?

Re:60 days is not 5 (1)

abigsmurf (919188) | more than 4 years ago | (#32975364)

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

Re:60 days is not 5 (0)

Anonymous Coward | more than 4 years ago | (#32975486)

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 (1)

hkmwbz (531650) | more than 4 years ago | (#32975092)

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 (0)

Anonymous Coward | more than 4 years ago | (#32975652)

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 (0)

Anonymous Coward | more than 4 years ago | (#32977004)

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

Jeopardy! (3, Funny)

jrivar59 (146428) | more than 4 years ago | (#32974006)

I can only conclude that this Jeopardy! winner [youtube.com] now works for Google.

Google to Microsoft: (0)

mentil (1748130) | more than 4 years ago | (#32974278)

We've upped our ante; up yours!

Re:Google to Microsoft: (1)

AHuxley (892839) | more than 4 years ago | (#32974338)

$3640 ought to be enough for any report.

Re:Google to Microsoft: (1)

gmuslera (3436) | more than 4 years ago | (#32974550)

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.

I don't get it (2, Insightful)

T Murphy (1054674) | more than 4 years ago | (#32974798)

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

Re:I don't get it (1)

moonbender (547943) | more than 4 years ago | (#32975516)

You need to read it backwards!

0-day (1)

miffo.swe (547642) | more than 4 years ago | (#32975768)

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 (1)

bjourne (1034822) | more than 4 years ago | (#32976052)

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 (1)

mjwalshe (1680392) | more than 4 years ago | (#32976122)

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 (0)

Anonymous Coward | more than 4 years ago | (#32977184)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?