Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got read access on Google’s production servers

blog.detectify.com

Post reply on HN
Print view View original

181–190 of 197 posts

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

#181

Post by muyuu »

nostrademons wrote: post #154
muyuu wrote: post #97

Earlier quoted context omitted.

Nope but if you have root in production servers you can just peruse the RAM. Nice throwaway. LOL.

It's probably cryptographically hashed. There is no reason to keep a raw password in RAM beyond the stack frame of the function that receives it from the client - at any point after that, just store & compare the hash.

It would still be catastrophic if they had access to the hashed passwords of a big number of users. People use weak passwords and they get cracked in no time if you have just a hash.

But as I said before, that also depends on some details about the setup that we don't know from this article alone.

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

#183

Post by fabulist »

thrownaway2424 wrote: post #103
muyuu wrote: post #97

Earlier quoted context omitted.

Nope but if you have root in production servers you can just peruse the RAM. Nice throwaway. LOL.

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

To clarify what thrownaway2424 said, in case some people really are unfamiliar;

You can't take the password out of RAM. It would be pretty insane to store it in RAM once the login process is done.

This exploit can't read RAM. Being able to read RAM from a program other than the one you are exploiting is pretty unusual today (early operating systems were much less scrupulous, however). There are lots of scary local exploits that can do this by abusing the high level of privileges granted to drivers for things like HDMI devices, but I've never heard of a remote exploit that could read arbitrary RAM. You can sometimes convince a program to dump core if you have a DoS and can run ulimit.

We used to store passwords in /etc/passwd. The user database need to be public. So the passwords stored in it were hashed, and thus were thought to be secure. Along came the Morris worm, which used (among other things) MD4 password cracking to infect systems. I imagine there were less high-profile incidents as well, but the long and the short if it is we how use /etc/shadow for secrets, and /etc/passwd for usernames.

While not secret, I'd certainly call /etc/shadow sensitive, but its a small point.

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

#184

Post by bencoder »

cdelsolar wrote: post #141
mixmax wrote: 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.

Hmm a pretty cheap road trip for just ten dollars, and I'm also not sure why they thought it necessary to include an extra significant figure for cents.

Comma is actually used for decimal separator in more of the world than the period: http://en.wikipedia.org/wiki/File:DecimalSeparator.svg

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

#185

Post by [deleted] »

cdelsolar wrote: post #141
mixmax wrote: 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.

Hmm a pretty cheap road trip for just ten dollars, and I'm also not sure why they thought it necessary to include an extra significant figure for cents.

[deleted]

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

#187

Post by dannypgh »

spindritf wrote: post #10
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.

Or just move it to some cheap VPS where it cannot damage other services or your infrastructure.

Reputation is a form of infrastructure.

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

#188

Post by SixSigma »

eik3_de wrote: post #60
raverbashing wrote: post #48

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

scnr XML - It seemed like a good idea at the time

Not to everyone. Some of us greybeards tried to warn against it :

"XML is simply lisp done wrong." — Alan Cox

but the gee-whizzery won.

"XML combines the efficiency of text files with the readability of binary files" — unknown

"XML is a classic political compromise: it balances the needs of man and machine by being equally unreadable to both." — Matthew Might

Anyone remember XHTML ?

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

#189

Post by jmillikin »

jrockway wrote: post #147
gamegoblin wrote: post #138

Earlier quoted context omitted.

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.

More likely, they'll just write bindings to libxml2.

I wrote a libxml2 binding in Haskell (http://hackage.haskell.org/package/libxml-sax). It was an absolute nightmare, in part because handling entities safely requires a lot of hoop-jumping (and I'm not even 100% I caught all the places libxml2 does unsafe stuff).

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

#190

Post by mwcampbell »

I'm surprised nobody has mentioned containers, e.g. Docker, as a way of limiting the damage from this kind of bug. In a container whose only purpose is to run the application, /etc/passwd should be as uninteresting as:

    root:x:0:0:root:/:/bin/sh
    bin:x:1:1:bin:/dev/null:/sbin/nologin
    nobody:x:99:99:nobody:/dev/null:/sbin/nologin
    app:x:100:100:app:/app:/bin/sh
Post reply on HN