19.5.1. Problem

19.5.2. Solution

system("command $input @files");            # UNSAFE

Write it this way instead:

system("command", $input, @files);          # safer

19.5.3. Discussion

Because Perl was designed as a glue language, it's easy to use it to call other programs—too easy, in some cases.

It's safe to use backticks in a CGI script only if the arguments you give the program are internally generated, as in:

chomp($now = `date`);

But if the command within the backticks contains user-supplied input, perhaps like this:

@output = `grep $input @files`;

you have to be much more careful.

die "cannot fork: $!" unless defined ($pid = open(SAFE_KID, "-|"));
if ($pid =  = 0) {
    exec('grep', $input, @files) or die "can't exec grep: $!";
} else {
    @output = <SAFE_KID>;
    close SAFE_KID;                 # $? contains status
}

This works because exec, like system, permits a calling convention that's immune to shell escapes. When passed a list, no shell is called, and so no escapes can occur.

Similar circumlocutions are needed when using open to start up a command. Here's a safe backtick or piped open for read. Instead of using this unsafe code:

open(KID_TO_READ, "$program @options @args |");    # UNSAFE

use this more complicated but safer code:

# add error processing as above
die "cannot fork: $!" unless defined($pid = open(KID_TO_READ, "-|"));

if ($pid) {   # parent
   while (<KID_TO_READ>) {
       # do something interesting
   }
   close(KID_TO_READ)               or warn "kid exited $?";

} else {      # child
   # reconfigure, then
   exec($program, @options, @args)  or die "can't exec program: $!";
}

Here's a safe piped open for writing. Instead of using this unsafe code:

open(KID_TO_WRITE, "|$program $options @args");   # UNSAFE

use this more complicated but safer code:

die "cannot fork: $!" unless defined($pid = open(KID_TO_WRITE, "-|"));
$SIG{PIPE} = sub { die "whoops, $program pipe broke" };

if ($pid) {  # parent
   for (@data) { print KID_TO_WRITE $_ }
   close(KID_TO_WRITE)              or warn "kid exited $?";

} else {     # child
   # reconfigure, then
   exec($program, @options, @args)  or die "can't exec program: $!";
}

Put any extra security measures you'd like where the comment in the code says reconfigure. You can change environment variables, reset temporary user or group ID values, change directories or umasks, etc. You're in the child process now, where changes won't propagate back to the parent.

If you don't have any reconfiguration to do in the child process, and you're running at least the v5.8 release of Perl, open supports a list of separate parameters that works as system and exec do when passed a list; that is, it avoids the shell altogether. Those two calls would be:

open(KID_TO_READ, "-|", $program, @options, @args)
    || die "can't run $program: $!";

and:

open(KID_TO_WRITE, "|-", $program, $options, @args)
      || die "can't run $program: $!";

This doesn't help you, of course, if you run a setuid program that can be exploited with the data you give it. The mail program sendmail is a setuid program commonly run from CGI scripts. Know the risks before you call sendmail or any other setuid program.

19.5.4. See Also