Live data from Hacker News

How we got read access on Google’s production servers

blog.detectify.com

131–140 of 197 posts

Re: How we got read access on Google’s production servers

#131
post #9

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.

Call me an idealist, but I think 10,000 could be low.

Re: How we got read access on Google’s production servers

#132
post #87

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

> I just saw that the local bank my parents use is still vulnerable to the Heartbleed Bug.

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

#133

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

I do now! Thanks for makin me feel better =)

Re: How we got read access on Google’s production servers

#134

This 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 powerful and dangerous.

Re: How we got read access on Google’s production servers

#135

This 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…

There is a big difference between a web browser in your local machine and a server processing all untrusted data that is thrown at him

Re: How we got read access on Google’s production servers

#136

Earlier 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?

Protect your clients by fixing the product even if the engineers don't care much anymore, not by suddenly discontinuing something your clients came to depend upon, without even giving them alternatives.

Re: How we got read access on Google’s production servers

#137
post #9

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.

Where _is_ Google's response?

Re: How we got read access on Google’s production servers

#138
post #121
post #74

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

Even with haskell, someone could sneak in a performUnsafeIO call if you aren't careful. Of course this is trivial to detect with compiler flags etc.

Re: How we got read access on Google’s production servers

#140

Very 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…

These payouts are for product vulnerabilities; things that Microsoft and Google ship to customers; vulnerabilities that those vendors are effectively creating on hundreds of thousands of machines they don't own.
Post reply on HN