You may not use data derived from outside your program to affect
something else outside your program--at least, not by accident. All
command line arguments, environment variables, locale information (see
-L<perllocale>), results of certain system calls (readdir, readlink,
-the gecos field of getpw* calls), and all file input are marked as
-"tainted". Tainted data may not be used directly or indirectly in any
-command that invokes a sub-shell, nor in any command that modifies
-files, directories, or processes. Any variable set
-to a value derived from tainted data will itself be tainted,
-even if it is logically impossible for the tainted data
-to alter the variable. Because taintedness is associated with each
-scalar value, some elements of an array can be tainted and others not.
+L<perllocale>), results of certain system calls (readdir(),
+readlink(), the variable of shmread(), the messages returned by
+msgrcv(), the password, gcos and shell fields returned by the
+getpwxxx() calls), and all file input are marked as "tainted".
+Tainted data may not be used directly or indirectly in any command
+that invokes a sub-shell, nor in any command that modifies files,
+directories, or processes, B<with the following exceptions>:
+
+=over 4
+
+=item *
+
+If you pass more than one argument to either C<system> or C<exec>,
+the arguments are B<not> checked for taintedness.
+
+=item *
+
+Arguments to C<print> and C<syswrite> are B<not> checked for taintedness.
+
+=back
+
+The value of an expression containing tainted data will itself be
+tainted, even if it is logically impossible for the tainted data to
+affect the value.
+
+Because taintedness is associated with each scalar value, some
+elements of an array can be tainted and others not.
For example:
unlink $data, $arg; # Insecure
umask $arg; # Insecure
- exec "echo $arg"; # Insecure
+ exec "echo $arg"; # Insecure (uses the shell)
exec "echo", $arg; # Secure (doesn't use the shell)
exec "sh", '-c', $arg; # Considered secure, alas!
- @files = <*.c>; # Always insecure (uses csh)
- @files = glob('*.c'); # Always insecure (uses csh)
+ @files = <*.c>; # insecure (uses readdir() or similar)
+ @files = glob('*.c'); # insecure (uses readdir() or similar)
+
+ # In Perl releases older than 5.6.0 the <*.c> and glob('*.c') would
+ # have used an external program to do the filename expansion; but in
+ # either case the result is tainted since the list of filenames comes
+ # from outside of the program.
+
+ $bad = ($arg, 23); # $bad will be tainted
+ $arg, `true`; # Insecure (although it isn't really)
If you try to do something insecure, you will get a fatal error saying
-something like "Insecure dependency" or "Insecure PATH". Note that you
+something like "Insecure dependency" or "Insecure $ENV{PATH}". Note that you
can still write an insecure B<system> or B<exec>, but only by explicitly
-doing something like the last example above.
+doing something like the "considered secure" example above.
=head2 Laundering and Detecting Tainted Data
-To test whether a variable contains tainted data, and whose use would thus
-trigger an "Insecure dependency" message, check your nearby CPAN mirror
-for the F<Taint.pm> module, which should become available around November
-1997. Or you may be able to use the following I<is_tainted()> function.
+To test whether a variable contains tainted data, and whose use would
+thus trigger an "Insecure dependency" message, you can use the
+tainted() function of the Scalar::Util module, available in your
+nearby CPAN mirror, and included in Perl starting from the release 5.8.0.
+Or you may be able to use the following I<is_tainted()> function.
sub is_tainted {
- return ! eval {
- join('',@_), kill 0;
- 1;
- };
+ return ! eval { eval("#" . substr(join("", @_), 0, 0)); 1 };
}
This function makes use of the fact that the presence of tainted data
to the shell. Use of C</.+/> would have been insecure in theory because
it lets everything through, but Perl doesn't check for that. The lesson
is that when untainting, you must be exceedingly careful with your patterns.
-Laundering data using regular expression is the I<ONLY> mechanism for
+Laundering data using regular expression is the I<only> mechanism for
untainting dirty data, unless you use the strategy detailed below to fork
a child of lesser privilege.
around and execute some other program that is dependent on your PATH, it
makes sure you set the PATH.
+The PATH isn't the only environment variable which can cause problems.
+Because some shells may use the variables IFS, CDPATH, ENV, and
+BASH_ENV, Perl checks that those are either empty or untainted when
+starting subprocesses. You may wish to add something like this to your
+setid and taint-checking scripts.
+
+ delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; # Make %ENV safer
+
It's also possible to get into trouble with other operations that don't
care whether they use tainted values. Make judicious use of the file
tests in dealing with any user-supplied filenames. When possible, do
best way to call something that might be subjected to shell escapes: just
never call the shell at all.
- use English;
- die "Can't fork: $!" unless defined $pid = open(KID, "-|");
- if ($pid) { # parent
- while (<KID>) {
- # do something
- }
- close KID;
- } else {
- my @temp = ($EUID, $EGID);
- $EUID = $UID;
- $EGID = $GID; # XXX: initgroups() not called
- # Make sure privs are really gone
- ($EUID, $EGID) = @temp;
- die "Can't drop privileges" unless
- $UID == $EUID and
- $GID eq $EGID; # String test
- $ENV{PATH} = "/bin:/usr/bin";
- exec 'myprog', 'arg1', 'arg2' or
- die "can't exec myprog: $!";
- }
+ use English;
+ die "Can't fork: $!" unless defined($pid = open(KID, "-|"));
+ if ($pid) { # parent
+ while (<KID>) {
+ # do something
+ }
+ close KID;
+ } else {
+ my @temp = ($EUID, $EGID);
+ my $orig_uid = $UID;
+ my $orig_gid = $GID;
+ $EUID = $UID;
+ $EGID = $GID;
+ # Drop privileges
+ $UID = $orig_uid;
+ $GID = $orig_gid;
+ # Make sure privs are really gone
+ ($EUID, $EGID) = @temp;
+ die "Can't drop privileges"
+ unless $UID == $EUID && $GID eq $EGID;
+ $ENV{PATH} = "/bin:/usr/bin"; # Minimal PATH.
+ # Consider sanitizing the environment even more.
+ exec 'myprog', 'arg1', 'arg2'
+ or die "can't exec myprog: $!";
+ }
A similar strategy would work for wildcard expansion via C<glob>, although
you can use C<readdir> instead.
Compile this wrapper into a binary executable and then make I<it> rather
than your script setuid or setgid.
-See the program B<wrapsuid> in the F<eg> directory of your Perl
-distribution for a convenient way to do this automatically for all your
-setuid Perl programs. It moves setuid scripts into files with the same
-name plus a leading dot, and then compiles a wrapper like the one above
-for each of them.
-
In recent years, vendors have begun to supply systems free of this
inherent security bug. On such systems, when the kernel passes the name
of the set-id script to open to the interpreter, rather than using a
should never have to specify this yourself. Most modern releases of
SysVr4 and BSD 4.4 use this approach to avoid the kernel race condition.
-Prior to release 5.003 of Perl, a bug in the code of B<suidperl> could
-introduce a security hole in systems compiled with strict POSIX
-compliance.
+Prior to release 5.6.1 of Perl, bugs in the code of B<suidperl> could
+introduce a security hole.
=head2 Protecting Your Programs
the source code has to be readable in order to be compiled and
interpreted. (That doesn't mean that a CGI script's source is
readable by people on the web, though.) So you have to leave the
-permissions at the socially friendly 0755 level.
+permissions at the socially friendly 0755 level. This lets
+people on your local system only see your source.
-Some people regard this as a security problem. If your program does
+Some people mistakenly regard this as a security problem. If your program does
insecure things, and relies on people not knowing how to exploit those
insecurities, it is not secure. It is often possible for someone to
determine the insecure things and exploit them without viewing the
source. Security through obscurity, the name for hiding your bugs
instead of fixing them, is little security indeed.
-You can try using encryption via source filters (Filter::* from CPAN).
-But crackers might be able to decrypt it. You can try using the
-byte code compiler and interpreter described below, but crackers might
-be able to de-compile it. You can try using the native-code compiler
+You can try using encryption via source filters (Filter::* from CPAN,
+or Filter::Util::Call and Filter::Simple since Perl 5.8).
+But crackers might be able to decrypt it. You can try using the byte
+code compiler and interpreter described below, but crackers might be
+able to de-compile it. You can try using the native-code compiler
described below, but crackers might be able to disassemble it. These
pose varying degrees of difficulty to people wanting to get at your
code, but none can definitively conceal it (this is true of every
Your access to it does not give you permission to use it blah blah
blah." You should see a lawyer to be sure your licence's wording will
stand up in court.
+
+=head1 SEE ALSO
+
+L<perlrun> for its description of cleaning up environment variables.