How we got read access on Google’s production servers • Hacker News Board

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

#121

Post by Peaker » Fri, Apr 11, 2014, 4:14 PM UTC

jerf wrote: post #74

bambax wrote: post #14

Earlier quoted context omitted.

> every time I write code to parse some XML Why would you write code to parse XML? Use an existing parser to parse. Use XSLT to modify/transform (including generate JSON/CSV/other).

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

#122

Post by darkarmani » Fri, Apr 11, 2014, 4:14 PM UTC

4ad wrote: post #15

Just $10k? This sells for at least 10 times more on the black market. Why would one rationally chose to "sell" this to google instead of the black market. Some people don't break the law because they are afraid to get caught, but I like to believe that most people don't break the law because of the moral aspect. To me at least, selling this on the black market poses no moral questions, so, leaving aside "I'm afraid t…

> To me at least, selling this on the black market poses no moral questions

That's probably a reflection of your own morals. There are millions of people that could be affected by this bug, so I'm not sure how there isn't a moral question here.

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

#123

Post by bitJericho » Fri, Apr 11, 2014, 4:16 PM UTC

4ad wrote: post #15

Just $10k? This sells for at least 10 times more on the black market. Why would one rationally chose to "sell" this to google instead of the black market. Some people don't break the law because they are afraid to get caught, but I like to believe that most people don't break the law because of the moral aspect. To me at least, selling this on the black market poses no moral questions, so, leaving aside "I'm afraid t…

You're right Google should pay out 100k for all exploits turned in.

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

#124

Post by saalweachter » Fri, Apr 11, 2014, 4:28 PM UTC

ephemeralgomi wrote: post #117

thrownaway2424 wrote: post #103

Earlier quoted context omitted.

This isn't a root exploit. It serves up files that are readable by the serving process, such as /etc/passwd. You are aware, I hope because it's been this way for 20+ years, that despite the name there are no passwords in /etc/passwd, right? It's not considered a sensitive file. % ls -l /etc/passwd -rw-r--r-- 1 root root 2028 Dec 2 13:05 /etc/passwd

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

#125

Post by sirdarckcat » Fri, Apr 11, 2014, 4:31 PM UTC

cookiecaper wrote: post #38

4ad wrote: post #15

Just $10k? This sells for at least 10 times more on the black market. Why would one rationally chose to "sell" this to google instead of the black market. Some people don't break the law because they are afraid to get caught, but I like to believe that most people don't break the law because of the moral aspect. To me at least, selling this on the black market poses no moral questions, so, leaving aside "I'm afraid t…

Maybe I just read it wrong but it sounds like Google made an opening offer and the security group felt it was sufficient and decided to take it instead of negotiating. Maybe I'm wrong and they'd already given the details and Google was just trying to keep them happy and provide some cash for what otherwise would've been a Good Samaritan, open-source contributor type of report. As long as Google is willing to negotiat…

Hi!

Bounties are always awarded after the bug is disclosed[1].

We constantly[2] upgrade the bounties whenever we feel like we should be paying more, and we will continue to do so. We also increase the rewards from the amounts in the price list if we think they result in a higher impact than what the reporter originally suspected.

We aren't actually trying to out-pay the black market. Overall, our goal is to reward the security community for their time and help for their security research, since we both have the same goal in common of keeping all of us safe (either Google services, or open source/popular software[3]).

And if you are interested, you can follow news on Google's VRP here: - https://plus.google.com/communities/103663928590757646624

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

#126

Post by iffycan » Fri, Apr 11, 2014, 4:32 PM UTC

numair wrote: post #2

... And this is why you want to discontinue products and services your engineers can't be motivated to maintain. Amazing. This should scare anyone who has ever left an old side project running; I could see a lot of companies doing a product/service portfolio review based on this as a case study.

I recently deleted a decade old CGI script called "db" that would execute arbitrary database queries for you. No one remembered it was there.

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

#127

Post by wpietri » Fri, Apr 11, 2014, 4:37 PM UTC

ori_b wrote: post #111

jebblue wrote: post #81

Earlier quoted context omitted.

XML made it for more manageable to create machine to machine API's. I can say we surely would not want go back to the 80's and 90's when dong that stuff was a nightmare.

Yes, it was a drunken, stumbling step forward. Let's take another one, and move to something simpler, which solves the problem better. To quote Phil Wadler's paper about XML, where he established some of the principles that influenced Xquery: "So the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."[1] I suggest reading the entire paper; It shows a number of shortcomi…

Hm. In his introduction, he says, "XML is touted as an external format for representing data." To me that mostly misses the value of XML. I think of it as an interchange format, not a closely-mirror-my-datastructures format. I've used it before when I want a long-lived data format that is mostly annotated text, and I'd happily do it again.

That said, I'm very skeptical of the XML-for-everything school, and nearly murdered a group of engineers who were using XML to transfer data from one spot in an app to another, even though it all ran in the same JVM. So maybe I'm more defending a small subset of XML rather than the XML-industrial complex.

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

#128

Post by dreamdu5t » Fri, Apr 11, 2014, 4:42 PM UTC

thrownaway2424 wrote: post #106

kirab wrote: post #98

I think they couldn’t read /etc/shadow, so it’s not that bad at first. But then they could surely access some configuration file of the application itself, probably containing DB creds and of course more information which helps to find more vulns.

It's shocking to me that baking "db creds" into a binary or configuration file is still so common that anyone would expect it to be true on a randomly selected server. Is this still the industry standard?

How else would you do it? If you use a configuration "service" the credentials to access the service must be baked in.

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

#129

Post by skybrian » Fri, Apr 11, 2014, 4:43 PM UTC

numair wrote: post #2

... And this is why you want to discontinue products and services your engineers can't be motivated to maintain. Amazing. This should scare anyone who has ever left an old side project running; I could see a lot of companies doing a product/service portfolio review based on this as a case study.

I'm quite happy with App Engine for unmaintained side projects. Very few upgrades are needed and your crufty code is quite well encapsulated. For something like the heartbleed bug there's nothing to do.

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

#130

Post by VikingCoder » Fri, Apr 11, 2014, 4:44 PM UTC

TallGuyShort wrote: post #94

borski wrote: 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".

One idea: Call your local newspaper with an anonymous tip?