[matt4077]

I don't quite understand how this is different from the status quo? I guess gems may (sometimes) be installed with a different user (or even root) than the application server?

But even if: most systems today probably only run that one service, and the application server can rwx pretty much everything of interest because that's its job, right?

10 years or so ago you'd often see some company's server running apache as well as a mail server, the internal document repository and the financial systems. In that sort of setup, it's important to (try to) keep these systems isolated from each other. But today, all that root access would give you is the ability to read a few more Ubuntu man pages.

[quacker]

I wouldn't be so optimistic. There are often credentials to other systems (like databases, etc) on such servers, plus they now have access to the private network(s) the compromised server resides on. It gives the attacker the opportunity to serve exploits to users, to forward incoming requests from users to external servers (maybe there's an auth token or something they can use), and tons of other stuff.

[lotyrin]

Yep. Even if you only owned a perfectly sterile (no secrets) proxy tier to a distinct service tier, you are placed in the path of requests from clients to those services and can thereby extract credentials (passwords, tokens) or PII (names, emails), which would still be unacceptable.

[jrochkind1]

> and the application server can rwx pretty much everything of interest because that's its job, right?

Eh, I don't know about that. I don't think most application servers are running as root, and I'm pretty sure it's considered bad practice to run them as root, no?

But yeah, they still need to have enough privs to do their jobs, which will be a lot of privs. But you still don't go from that to "might as well just run as root then".

[pmontra]

Developer machines could be as interesting as servers, maybe more. If they can install a keylogger using a malicious or hijacked gem, then bingo!

The file overwrite and the ANSI sequence vulnerabilities are extra attack vectors. The main one has anyways been the code itself and its vetting process. This for Ruby gems and for any other open and closed source piece of code we run on our machines, starting from the processor(s) microcode.