Installing Development Tools on Production Server? Security Risk?

Question

I am using an Amazon Linux EC2 instance as a web server. My web app uses ImageMagick. Because the Amazon Linux (CentOS) repository doesn't include an up-to-date version of ImageMagick, I am compiling it from source. To do this I run:

yum groupinstall 'Development Tools'

Does installing development tools on a production serve pose a security risk? If so, how do I go about safely removing what I shouldn't have installed?

Answer 1

The general rule for systems is: if you don't need it, don't install it. Perhaps we should modify that to: if you no longer need it, uninstall it.

Why? To reduce the "attack surface" available on the system - i.e. programs and utilities that can be compromised or used as part of a compromise. That's the general justification.

The specific risk for development tools is that if an attacker gains access to an unprivileged user, chances are they can then use say gcc to compile arbitrary code on your box. That said - chances are also high that you're running an interpreter such as python, or have javac around for web applications or some such - so the actual material impact might not be much different.

I personally see nothing wrong with installing the dev tools (I'd pull them in manually with yum install <tool> so they can be then yum remove'd later) and then removing them after their purpose is fulfilled. After all, all this talk of compiling abitrary code under unprivileged users actually misses the point: at that stage, somebody has already gained a foothold on your system and that is what you want to prevent.

Policy-wise, not having development tools on a webserver is in my mind a good idea - it discourages developers from "doing it live". Not that we would, mind, but well... we probably would :)

Answer 2

In addition to @Karrax's correct answer, regarding increased attack surface, possible exploits, and easier attack environment for a potential hacker, I wanted to point out one more issue that should be obvious, but is often painfully not.

These are development tools. On a production server.
I infer from that, that not only do the developers have access to the production server, they apparently intend on developing on it.
This by itself has a whole bunch of risks associated with it, namely:

• Unauthorized access to production data
• No Least Privilege possible
• No Segregation of Duties (SoD)
• Highly probably there are lots of old, test, and unused code files
• Highly probably there are lots of old, test, and unused configuration files - e.g. with a .bak filetype, allowing any user to download and steal passwords etc
• No security testing before deployment
• Easy to pop in hidden backdoors, because of the previous
• Obviously, there is no SDL (security development lifecycle) in place
• And more.

My point is that the problem isn't just installing the development tools, its the bigger problem is the process and environment around it that would cause such a plan in the first place.

Answer 3

Yes, any addition to software you install on your environment will increase the attack surface an attacker may use to compromise you and your systems.

The tools in this package can contain known exploits or other not yet discovered exploits that can further compromise your system.

In general I would say it is best practice to keep development and production as separated as possible, however each business may have its own risk/consequence and cost analysis so maybe in your specific case it may be acceptable risk.

Do note that in your case you are installing 'development tools'! This can pose an extra security risk as you are essentially leaving a perfectly good compiler (and other tools) designed for this specific system, on your system. In many cases this just makes it more trivial for the attacker to compile and run more exploit code once you've been compromised, however in some special cases (where you perhaps need a special compiler) will make it way too easy for the attacker once you've been compromised.

EDIT: As Gilles comment the latter example is highly unlikely in your specific case. I'd like to quote Gilles as it is exactly what I meant to bring into my example:

on a system where the attacker has limited bandwidth or can only inject printable characters, or on an exotic system for which obtaining a compiler or building one's own is expensive. But here we're talking about a system with a fast network connection and that the attacker can reproduce for a few dollars