Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from Feb 24 '12 at 8:21

This question came from our site for system and network administrators.

up vote 10 down vote accepted

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

share|improve this answer

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.

share|improve this answer
Love you answer @Avid. I'd +1 the +1 if I could. – Chris Dale Feb 24 '12 at 11:07
While I agree with your post, you shoudl re-read his statement. He said he's installing the developer tools so that he can compile the latest version of ImageMagick, which is an open source image manipulation library that is often used in PHP and Perl applications, from the source code. – AlanBarber Feb 24 '12 at 14:13
@AlanBarber The asker should instead compile the code on another EC2 instance (or another Linux machine altogether), deploy the resulting binary package to a development version of the server (which may be that same EC2 instance used for compiling), and if tests pass, deploy the same binary package to the production server. – Gilles Feb 24 '12 at 18:08
@Gilles bingo, that's the correct steps the people should take when managing production servers. – AlanBarber Feb 24 '12 at 21:34
@AviD your message is not an answer to my question, it is sort of a lecture on not developing on a production server, which is an incorrect assumption you made. – evan Feb 25 '12 at 5:45

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

share|improve this answer
Development tools will only make exploitation marginally easier. Compilers for Linux EC2 are trivial to come by, and network access is presumed, so local availability doesn't matter. The development tools themselves aren't running as services. What is a risk is if the attacker attacks a running development tool (e.g. that uses an insecure temporary file) to escalate a local privilege to another user; this is a risk of running the vulnerable tool, not directly of having it installed. – Gilles Feb 24 '12 at 18:07
@Gilles, What I ment is that some systems are required to have special compilers. If you leave them on the system you make the job much more easy. I wish I had a concrete example for you, but I don't atm. I am just quoting Ed Skoudis on this. – Chris Dale Feb 24 '12 at 18:23
Sure, sometimes the absence of development tools will make exploits more difficult: 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. – Gilles Feb 24 '12 at 18:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.