In large production environments it's almost impossible to avoid bugs - and some of them are going to be nasty. What sets great and security conscious companies apart from the rest is how they deal with them. This is an examplary response from google. They respond promptly (with humor no less) and thank the guys that found the bug. Then they proceeded to pay out a bounty of $10.000. Well done google.
How we got read access on Google’s production servers
131–140 of 197 posts
Re: How we got read access on Google’s production servers
#132Earlier quoted context omitted.
I am really glad about how they responded. Whenever Tinfoil has found vulnerabilities in companies like United Airlines[0], for example, those companies mostly respond with anger rather than graciousness. [0] https://www.tinfoilsecurity.com/blog/132969897
Exactly. I just saw that the local bank my parents use is still vulnerable to the Heartbleed Bug. But you know what? I don't want to go down there and talk to them because I'm quite certain they'll call the police because I "hacked into their systems".
Just remember, many sites use the old certificate expiration even though they generated new certificates which shows up as a false positive on the checking tools.
Re: How we got read access on Google’s production servers
#133Earlier quoted context omitted.
I'm kind of sad that this is a throwaway account because you're posting good responses, that are technically competent and are actually specific to the bug discussed in the article, to people who are either less informed or are talking about their vague general understanding of vulnerabilities rather than reading the article and actually discussing its contents. Your posts are exactly the kind of thing I _want_ to re…
Uhh, you do realize his 'throwaway' account is two years old with hundreds of comments? I don't know if he's partitioning, hoarding, or being playful in account naming, but that's probably a better track record than most non-throwaway accounts on this site.
Re: How we got read access on Google’s production servers
#134This is another reason not to use XML, plain and simple It's too much hidden power in the hands of those who don't know what they're doing (loading external entities pointed in an XML automatically? what kind of joke is that?)
Where would we be if web browsers couldn't use external resources?
General-purpose parsers/renderers need have tightly locked down, sensible defaults, or even security-oriented feature subsets, but that doesn't mean we should remove one of their most useful features altogether, or avoid them because they're powerful and dangerous.
Re: How we got read access on Google’s production servers
#135This is another reason not to use XML, plain and simple It's too much hidden power in the hands of those who don't know what they're doing (loading external entities pointed in an XML automatically? what kind of joke is that?)
That's an overly narrow view. We shouldn't avoid powerful features merely because power can cause problems. Where would we be if web browsers couldn't use external resources? General-purpose parsers/renderers need have tightly locked down, sensible defaults, or even security-oriented feature subsets, but that doesn't mean we should remove one of their most useful features altogether, or avoid them because they're pow…
Re: How we got read access on Google’s production servers
#136Earlier quoted context omitted.
Or just move it to some cheap VPS where it cannot damage other services or your infrastructure.
Or your reputation or your ethical and possibly legal duty to protect your clients?
Re: How we got read access on Google’s production servers
#137In large production environments it's almost impossible to avoid bugs - and some of them are going to be nasty. What sets great and security conscious companies apart from the rest is how they deal with them. This is an examplary response from google. They respond promptly (with humor no less) and thank the guys that found the bug. Then they proceeded to pay out a bounty of $10.000. Well done google.
Re: How we got read access on Google’s production servers
#138Earlier quoted context omitted.
Ironically, using an existing parser is what opens you to this vulnerability in the first place. If you hack your own together based on a vague idea of what XML really is, you're very unlikely to "correctly" handle entities, you'll probably just put in enough to handle simple XHTML entities, and that makes you immune to this problem! It's the compliant parsers that are vulnerable to this....
Or, if you use existing parsers in a language like Haskell, you know parsing is supposed to be a pure function. If parsing suddenly requires IO effects, you can be suspicious and try to figure out what is going on.
Re: How we got read access on Google’s production servers
#139Re: How we got read access on Google’s production servers
#140Very cool hack. Is $10,000 around the top end of what Google will pay out? This seems like quite a serious bug as far as they go.
No, You can see the general payout levels here: http://www.google.com/about/appsecurity/reward-program/ , normally the top payout is about $ 20,000, but the top payout (for Chrome) currently 2 people have been rewarded with $ 60,000. There is an overview of the top payouts though: http://www.chromium.org/Home/chromium-security/hall-of-fame . Some payouts are $1337 ,$3133.7 or $31336 :P Microsoft rewards even up to $1…