[thrownaway2424]

Yes golly you must be right, i bet google just uses rsync to copy the passwords of billions of user accounts to thousands upon thousands of machines all over the world, in plain text! It's probably in /var/lib/every_user_password_in_plain_text.txt!

[muyuu]

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

Nice throwaway. LOL.

[thrownaway2424]

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

[ephemeralgomi]

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 read on HN. Is there a particular reason why you feel you can't post this under a general-use account?

[saalweachter]

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.

[ephemeralgomi]

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

[fabulist]

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.

[muyuu]

The severity of this bug depends on the privileges and the setup of whatever user ran that service then.

[slantedview]

And yet it was worth 10k to google.

[nostrademons]

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.

[muyuu]

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.

[chongli]

They didn't have root, they had whatever user the XML parser was running as.