Server Fault is a question and answer site for system and network administrators. 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

So we found that some trojan has been the cause of our two web servers crashing once a week as we found that perl was executing dozens of malicious "gif" files spiking the memory and eventually restarting the boxes. We're only using the box for PHP and some general nix-y things like chrontabs. Is it possible to disable perl and not uninstall completely? If not any problem with PHP not having perl on the box?

Apologies, I'm a .NET developer working with some LAMP stuff right now and this is just a touch out of my comfort zone.

Thanks. Bryan

share|improve this question
As noted below, disabling perl is a potentially server crashing solution. The best solution is to find the security flaw and patch it. More than like this is caused by an older, exploitable version of some web application you have running. Try running something like nikto2 against your server to find any obvious vulnerabilities. – Kyle Nov 1 '11 at 21:43

It looks to me that you pose the wrong question. And you'll probably will get wrong answers to your original questions (as in easily worked around)

If you have a trojan, "disabling" the execution of programming languages is not the right thing to do.

What's the right thing to do? Patch your servers. Make them secure (and ideally, hire a UNIX System Engineer).

Some questions for you:

  • What will you do once the trojan is executing files in the native Executable and Linkable Format (elf). Will you disable the execution of C-programs (hint: remove libc [Just kidding])?
  • What if the trojan has the interpreter embedded (e.g., pp does this on perl)?
  • What if the script is run in some indirect way?
  • ...

By the way, "disabling" the execution of programming languages, and specially Perl on UNIX, will break a lot of stuff. A *lot*.


share|improve this answer
So we've patched what was identified and also have done analysis on what is using Perl (thus far only Git) as the server is very lightweight and only hosts one php site. Also, I was looking to disable perl and not uninstall it precisely to test some functionality and to verify what we think was patched, was in fact patched. – BryanGrimes Nov 2 '11 at 14:52
I don't see many differences between disabling and removing. When Perl is marked as a dependency, it means the package in question needs Perl (or whatever other dependency it has). When you remove the package, the system know that it misses required elements (and may remove the packages because the dependencies are not met). When "disabling" --it seems you mean "make not executable"-- the system in question does not know about your broken setup and takes the dependencies for granted: the application will probably crash or it will not function as intended (otherwise it's not a dependency). – nxadm Nov 2 '11 at 17:14
Are you sure you are not confusing your request with disabling installed services (something common on UNIX)? – nxadm Nov 2 '11 at 17:18

Turn off the executable bits:

sudo chmod a-x `which perl`
share|improve this answer
+1 - Beat me to it! – gWaldo Nov 1 '11 at 20:46

One quick thing that could be done would be to temporarily rename the Perl binary from /usr/bin/perl to /usr/bin/perl.SAVE

share|improve this answer
thanks, I'll do that now. Would this be for each user including root? – BryanGrimes Nov 1 '11 at 19:44
You only have to do it once. /usr/bin/ is a global bin path. – Kyle Nov 1 '11 at 21:36

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.