You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
365 lines
17 KiB
365 lines
17 KiB
=head1 NAME
|
|
|
|
perlsec - Perl security
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
Perl is designed to make it easy to program securely even when running
|
|
with extra privileges, like setuid or setgid programs. Unlike most
|
|
command line shells, which are based on multiple substitution passes on
|
|
each line of the script, Perl uses a more conventional evaluation scheme
|
|
with fewer hidden snags. Additionally, because the language has more
|
|
builtin functionality, it can rely less upon external (and possibly
|
|
untrustworthy) programs to accomplish its purposes.
|
|
|
|
Perl automatically enables a set of special security checks, called I<taint
|
|
mode>, when it detects its program running with differing real and effective
|
|
user or group IDs. The setuid bit in Unix permissions is mode 04000, the
|
|
setgid bit mode 02000; either or both may be set. You can also enable taint
|
|
mode explicitly by using the B<-T> command line flag. This flag is
|
|
I<strongly> suggested for server programs and any program run on behalf of
|
|
someone else, such as a CGI script. Once taint mode is on, it's on for
|
|
the remainder of your script.
|
|
|
|
While in this mode, Perl takes special precautions called I<taint
|
|
checks> to prevent both obvious and subtle traps. Some of these checks
|
|
are reasonably simple, such as verifying that path directories aren't
|
|
writable by others; careful programmers have always used checks like
|
|
these. Other checks, however, are best supported by the language itself,
|
|
and it is these checks especially that contribute to making a set-id Perl
|
|
program more secure than the corresponding C program.
|
|
|
|
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 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 a list of arguments to either C<system> or C<exec>,
|
|
the elements of that list are B<not> checked for taintedness.
|
|
|
|
=item *
|
|
|
|
Arguments to C<print> and C<syswrite> are B<not> checked for taintedness.
|
|
|
|
=back
|
|
|
|
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.
|
|
|
|
For example:
|
|
|
|
$arg = shift; # $arg is tainted
|
|
$hid = $arg, 'bar'; # $hid is also tainted
|
|
$line = <>; # Tainted
|
|
$line = <STDIN>; # Also tainted
|
|
open FOO, "/home/me/bar" or die $!;
|
|
$line = <FOO>; # Still tainted
|
|
$path = $ENV{'PATH'}; # Tainted, but see below
|
|
$data = 'abc'; # Not tainted
|
|
|
|
system "echo $arg"; # Insecure
|
|
system "/bin/echo", $arg; # Secure (doesn't use sh)
|
|
system "echo $hid"; # Insecure
|
|
system "echo $data"; # Insecure until PATH set
|
|
|
|
$path = $ENV{'PATH'}; # $path now tainted
|
|
|
|
$ENV{'PATH'} = '/bin:/usr/bin';
|
|
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
|
|
|
|
$path = $ENV{'PATH'}; # $path now NOT tainted
|
|
system "echo $data"; # Is secure now!
|
|
|
|
open(FOO, "< $arg"); # OK - read-only file
|
|
open(FOO, "> $arg"); # Not OK - trying to write
|
|
|
|
open(FOO,"echo $arg|"); # Not OK, but...
|
|
open(FOO,"-|")
|
|
or exec 'echo', $arg; # OK
|
|
|
|
$shout = `echo $arg`; # Insecure, $shout now tainted
|
|
|
|
unlink $data, $arg; # Insecure
|
|
umask $arg; # Insecure
|
|
|
|
exec "echo $arg"; # Insecure
|
|
exec "echo", $arg; # Secure (doesn't use the shell)
|
|
exec "sh", '-c', $arg; # Considered secure, alas!
|
|
|
|
@files = <*.c>; # insecure (uses readdir() or similar)
|
|
@files = glob('*.c'); # insecure (uses readdir() or similar)
|
|
|
|
If you try to do something insecure, you will get a fatal error saying
|
|
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 "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.
|
|
|
|
sub is_tainted {
|
|
return ! eval {
|
|
join('',@_), kill 0;
|
|
1;
|
|
};
|
|
}
|
|
|
|
This function makes use of the fact that the presence of tainted data
|
|
anywhere within an expression renders the entire expression tainted. It
|
|
would be inefficient for every operator to test every argument for
|
|
taintedness. Instead, the slightly more efficient and conservative
|
|
approach is used that if any tainted value has been accessed within the
|
|
same expression, the whole expression is considered tainted.
|
|
|
|
But testing for taintedness gets you only so far. Sometimes you have just
|
|
to clear your data's taintedness. The only way to bypass the tainting
|
|
mechanism is by referencing subpatterns from a regular expression match.
|
|
Perl presumes that if you reference a substring using $1, $2, etc., that
|
|
you knew what you were doing when you wrote the pattern. That means using
|
|
a bit of thought--don't just blindly untaint anything, or you defeat the
|
|
entire mechanism. It's better to verify that the variable has only good
|
|
characters (for certain values of "good") rather than checking whether it
|
|
has any bad characters. That's because it's far too easy to miss bad
|
|
characters that you never thought of.
|
|
|
|
Here's a test to make sure that the data contains nothing but "word"
|
|
characters (alphabetics, numerics, and underscores), a hyphen, an at sign,
|
|
or a dot.
|
|
|
|
if ($data =~ /^([-\@\w.]+)$/) {
|
|
$data = $1; # $data now untainted
|
|
} else {
|
|
die "Bad data in $data"; # log this somewhere
|
|
}
|
|
|
|
This is fairly secure because C</\w+/> doesn't normally match shell
|
|
metacharacters, nor are dot, dash, or at going to mean something special
|
|
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
|
|
untainting dirty data, unless you use the strategy detailed below to fork
|
|
a child of lesser privilege.
|
|
|
|
The example does not untaint $data if C<use locale> is in effect,
|
|
because the characters matched by C<\w> are determined by the locale.
|
|
Perl considers that locale definitions are untrustworthy because they
|
|
contain data from outside the program. If you are writing a
|
|
locale-aware program, and want to launder data with a regular expression
|
|
containing C<\w>, put C<no locale> ahead of the expression in the same
|
|
block. See L<perllocale/SECURITY> for further discussion and examples.
|
|
|
|
=head2 Switches On the "#!" Line
|
|
|
|
When you make a script executable, in order to make it usable as a
|
|
command, the system will pass switches to perl from the script's #!
|
|
line. Perl checks that any command line switches given to a setuid
|
|
(or setgid) script actually match the ones set on the #! line. Some
|
|
Unix and Unix-like environments impose a one-switch limit on the #!
|
|
line, so you may need to use something like C<-wU> instead of C<-w -U>
|
|
under such systems. (This issue should arise only in Unix or
|
|
Unix-like environments that support #! and setuid or setgid scripts.)
|
|
|
|
=head2 Cleaning Up Your Path
|
|
|
|
For "Insecure C<$ENV{PATH}>" messages, you need to set C<$ENV{'PATH'}> to a
|
|
known value, and each directory in the path must be non-writable by others
|
|
than its owner and group. You may be surprised to get this message even
|
|
if the pathname to your executable is fully qualified. This is I<not>
|
|
generated because you didn't supply a full path to the program; instead,
|
|
it's generated because you never set your PATH environment variable, or
|
|
you didn't set it to something that was safe. Because Perl can't
|
|
guarantee that the executable in question isn't itself going to turn
|
|
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
|
|
opens and such B<after> properly dropping any special user (or group!)
|
|
privileges. Perl doesn't prevent you from opening tainted filenames for reading,
|
|
so be careful what you print out. The tainting mechanism is intended to
|
|
prevent stupid mistakes, not to remove the need for thought.
|
|
|
|
Perl does not call the shell to expand wild cards when you pass B<system>
|
|
and B<exec> explicit parameter lists instead of strings with possible shell
|
|
wildcards in them. Unfortunately, the B<open>, B<glob>, and
|
|
backtick functions provide no such alternate calling convention, so more
|
|
subterfuge will be required.
|
|
|
|
Perl provides a reasonably safe way to open a file or pipe from a setuid
|
|
or setgid program: just create a child process with reduced privilege who
|
|
does the dirty work for you. First, fork a child using the special
|
|
B<open> syntax that connects the parent and child by a pipe. Now the
|
|
child resets its ID set and any other per-process attributes, like
|
|
environment variables, umasks, current working directories, back to the
|
|
originals or known safe values. Then the child process, which no longer
|
|
has any special permissions, does the B<open> or other system call.
|
|
Finally, the child passes the data it managed to access back to the
|
|
parent. Because the file or pipe was opened in the child while running
|
|
under less privilege than the parent, it's not apt to be tricked into
|
|
doing something it shouldn't.
|
|
|
|
Here's a way to do backticks reasonably safely. Notice how the B<exec> is
|
|
not called with a string that the shell could expand. This is by far the
|
|
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);
|
|
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.
|
|
|
|
Taint checking is most useful when although you trust yourself not to have
|
|
written a program to give away the farm, you don't necessarily trust those
|
|
who end up using it not to try to trick it into doing something bad. This
|
|
is the kind of security checking that's useful for set-id programs and
|
|
programs launched on someone else's behalf, like CGI programs.
|
|
|
|
This is quite different, however, from not even trusting the writer of the
|
|
code not to try to do something evil. That's the kind of trust needed
|
|
when someone hands you a program you've never seen before and says, "Here,
|
|
run this." For that kind of safety, check out the Safe module,
|
|
included standard in the Perl distribution. This module allows the
|
|
programmer to set up special compartments in which all system operations
|
|
are trapped and namespace access is carefully controlled.
|
|
|
|
=head2 Security Bugs
|
|
|
|
Beyond the obvious problems that stem from giving special privileges to
|
|
systems as flexible as scripts, on many versions of Unix, set-id scripts
|
|
are inherently insecure right from the start. The problem is a race
|
|
condition in the kernel. Between the time the kernel opens the file to
|
|
see which interpreter to run and when the (now-set-id) interpreter turns
|
|
around and reopens the file to interpret it, the file in question may have
|
|
changed, especially if you have symbolic links on your system.
|
|
|
|
Fortunately, sometimes this kernel "feature" can be disabled.
|
|
Unfortunately, there are two ways to disable it. The system can simply
|
|
outlaw scripts with any set-id bit set, which doesn't help much.
|
|
Alternately, it can simply ignore the set-id bits on scripts. If the
|
|
latter is true, Perl can emulate the setuid and setgid mechanism when it
|
|
notices the otherwise useless setuid/gid bits on Perl scripts. It does
|
|
this via a special executable called B<suidperl> that is automatically
|
|
invoked for you if it's needed.
|
|
|
|
However, if the kernel set-id script feature isn't disabled, Perl will
|
|
complain loudly that your set-id script is insecure. You'll need to
|
|
either disable the kernel set-id script feature, or put a C wrapper around
|
|
the script. A C wrapper is just a compiled program that does nothing
|
|
except call your Perl program. Compiled programs are not subject to the
|
|
kernel bug that plagues set-id scripts. Here's a simple wrapper, written
|
|
in C:
|
|
|
|
#define REAL_PATH "/path/to/script"
|
|
main(ac, av)
|
|
char **av;
|
|
{
|
|
execv(REAL_PATH, av);
|
|
}
|
|
|
|
Compile this wrapper into a binary executable and then make I<it> rather
|
|
than your script setuid or setgid.
|
|
|
|
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
|
|
pathname subject to meddling, it instead passes I</dev/fd/3>. This is a
|
|
special file already opened on the script, so that there can be no race
|
|
condition for evil scripts to exploit. On these systems, Perl should be
|
|
compiled with C<-DSETUID_SCRIPTS_ARE_SECURE_NOW>. The B<Configure>
|
|
program that builds Perl tries to figure this out for itself, so you
|
|
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.6.1 of Perl, bugs in the code of B<suidperl> could
|
|
introduce a security hole.
|
|
|
|
=head2 Protecting Your Programs
|
|
|
|
There are a number of ways to hide the source to your Perl programs,
|
|
with varying levels of "security".
|
|
|
|
First of all, however, you I<can't> take away read permission, because
|
|
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. This lets
|
|
people on your local system only see your source.
|
|
|
|
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
|
|
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
|
|
language, not just Perl).
|
|
|
|
If you're concerned about people profiting from your code, then the
|
|
bottom line is that nothing but a restrictive licence will give you
|
|
legal security. License your software and pepper it with threatening
|
|
statements like "This is unpublished proprietary software of XYZ Corp.
|
|
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.
|