9 ms·

So, when you have read access to googles prod servers, what else would be fun to do besides reading /etc/passwd ? Getting the source?

• willvarfar 13y ago
  Looking for more serious bugs? It could be the first steps on a major privilege escalation.
  • antocv 13y ago
    Where would you look?
    • thrownaway2424 13y ago
      /proc/self/exe
• skj 13y ago
  The source is not generally accessible from prod servers - only binaries and supporting data, and only the ones running on that computer. I guess it's possible you could find a computer that hosted both search and the codebase. But, since search is for external and the codebase is for internal, I'd be that they don't share clusters.
  • ithkuil 13y ago
    what if that file is per container and every software runs isolated? it's still a potential issue because you could retrieve other sensible information (log files?).
    • skj 13y ago
      Sure. I was only addressing the concern of accessing source.
• borplk 13y ago
  With the kind of monitoring that Google has in place your access will last a very short time.
  • thrownaway2424 13y ago
    What kind of monitoring would you deploy that would raise an alert for a process opening and reading readable files?
    • anonymouz 13y ago
      SELinux. This kind of stuff would be where it really shines. A correctly configured installation would block and report access to files the application is not supposed to access. Maintaining it, especially for individual applications, is work, but it seems to me that on the scale of Google it may well be worthwhile.
• muyuu 13y ago
  I'd say logins and passwords of millions of Google accounts would be the most valuable asset for a blackhat.
  • thrownaway2424 13y ago
    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 13y ago
      Nope but if you have root in production servers you can just peruse the RAM. Nice throwaway. LOL.
      • thrownaway2424 13y ago
        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
        • muyuu 13y ago
          The severity of this bug depends on the privileges and the setup of whatever user ran that service then.
        • ephemeralgomi 13y ago
          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?