[ Index ]

PHP Cross Reference of Unnamed Project




/se3-unattended/var/se3/unattended/install/linuxaux/opt/perl/lib/5.10.0/pod/ -> perlsec.pod (source)

   1  =head1 NAME
   3  perlsec - Perl security
   5  =head1 DESCRIPTION
   7  Perl is designed to make it easy to program securely even when running
   8  with extra privileges, like setuid or setgid programs.  Unlike most
   9  command line shells, which are based on multiple substitution passes on
  10  each line of the script, Perl uses a more conventional evaluation scheme
  11  with fewer hidden snags.  Additionally, because the language has more
  12  builtin functionality, it can rely less upon external (and possibly
  13  untrustworthy) programs to accomplish its purposes.
  15  Perl automatically enables a set of special security checks, called I<taint
  16  mode>, when it detects its program running with differing real and effective
  17  user or group IDs.  The setuid bit in Unix permissions is mode 04000, the
  18  setgid bit mode 02000; either or both may be set.  You can also enable taint
  19  mode explicitly by using the B<-T> command line flag. This flag is
  20  I<strongly> suggested for server programs and any program run on behalf of
  21  someone else, such as a CGI script. Once taint mode is on, it's on for
  22  the remainder of your script.
  24  While in this mode, Perl takes special precautions called I<taint
  25  checks> to prevent both obvious and subtle traps.  Some of these checks
  26  are reasonably simple, such as verifying that path directories aren't
  27  writable by others; careful programmers have always used checks like
  28  these.  Other checks, however, are best supported by the language itself,
  29  and it is these checks especially that contribute to making a set-id Perl
  30  program more secure than the corresponding C program.
  32  You may not use data derived from outside your program to affect
  33  something else outside your program--at least, not by accident.  All
  34  command line arguments, environment variables, locale information (see
  35  L<perllocale>), results of certain system calls (C<readdir()>,
  36  C<readlink()>, the variable of C<shmread()>, the messages returned by
  37  C<msgrcv()>, the password, gcos and shell fields returned by the
  38  C<getpwxxx()> calls), and all file input are marked as "tainted".
  39  Tainted data may not be used directly or indirectly in any command
  40  that invokes a sub-shell, nor in any command that modifies files,
  41  directories, or processes, B<with the following exceptions>:
  43  =over 4
  45  =item *
  47  Arguments to C<print> and C<syswrite> are B<not> checked for taintedness.
  49  =item *
  51  Symbolic methods
  53      $obj->$method(@args);
  55  and symbolic sub references
  57      &{$foo}(@args);
  58      $foo->(@args);
  60  are not checked for taintedness.  This requires extra carefulness
  61  unless you want external data to affect your control flow.  Unless
  62  you carefully limit what these symbolic values are, people are able
  63  to call functions B<outside> your Perl code, such as POSIX::system,
  64  in which case they are able to run arbitrary external code.
  66  =item *
  68  Hash keys are B<never> tainted.
  70  =back
  72  For efficiency reasons, Perl takes a conservative view of
  73  whether data is tainted.  If an expression contains tainted data,
  74  any subexpression may be considered tainted, even if the value
  75  of the subexpression is not itself affected by the tainted data.
  77  Because taintedness is associated with each scalar value, some
  78  elements of an array or hash can be tainted and others not.
  79  The keys of a hash are B<never> tainted.
  81  For example:
  83      $arg = shift;        # $arg is tainted
  84      $hid = $arg, 'bar';        # $hid is also tainted
  85      $line = <>;            # Tainted
  86      $line = <STDIN>;        # Also tainted
  87      open FOO, "/home/me/bar" or die $!;
  88      $line = <FOO>;        # Still tainted
  89      $path = $ENV{'PATH'};    # Tainted, but see below
  90      $data = 'abc';        # Not tainted
  92      system "echo $arg";        # Insecure
  93      system "/bin/echo", $arg;    # Considered insecure
  94                  # (Perl doesn't know about /bin/echo)
  95      system "echo $hid";        # Insecure
  96      system "echo $data";    # Insecure until PATH set
  98      $path = $ENV{'PATH'};    # $path now tainted
 100      $ENV{'PATH'} = '/bin:/usr/bin';
 101      delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
 103      $path = $ENV{'PATH'};    # $path now NOT tainted
 104      system "echo $data";    # Is secure now!
 106      open(FOO, "< $arg");    # OK - read-only file
 107      open(FOO, "> $arg");     # Not OK - trying to write
 109      open(FOO,"echo $arg|");    # Not OK
 110      open(FOO,"-|")
 111      or exec 'echo', $arg;    # Also not OK
 113      $shout = `echo $arg`;    # Insecure, $shout now tainted
 115      unlink $data, $arg;        # Insecure
 116      umask $arg;            # Insecure
 118      exec "echo $arg";        # Insecure
 119      exec "echo", $arg;        # Insecure
 120      exec "sh", '-c', $arg;    # Very insecure!
 122      @files = <*.c>;        # insecure (uses readdir() or similar)
 123      @files = glob('*.c');    # insecure (uses readdir() or similar)
 125      # In Perl releases older than 5.6.0 the <*.c> and glob('*.c') would
 126      # have used an external program to do the filename expansion; but in
 127      # either case the result is tainted since the list of filenames comes
 128      # from outside of the program.
 130      $bad = ($arg, 23);        # $bad will be tainted
 131      $arg, `true`;        # Insecure (although it isn't really)
 133  If you try to do something insecure, you will get a fatal error saying
 134  something like "Insecure dependency" or "Insecure $ENV{PATH}".
 136  The exception to the principle of "one tainted value taints the whole
 137  expression" is with the ternary conditional operator C<?:>.  Since code
 138  with a ternary conditional
 140      $result = $tainted_value ? "Untainted" : "Also untainted";
 142  is effectively
 144      if ( $tainted_value ) {
 145          $result = "Untainted";
 146      } else {
 147          $result = "Also untainted";
 148      }
 150  it doesn't make sense for C<$result> to be tainted.
 152  =head2 Laundering and Detecting Tainted Data
 154  To test whether a variable contains tainted data, and whose use would
 155  thus trigger an "Insecure dependency" message, you can use the
 156  C<tainted()> function of the Scalar::Util module, available in your
 157  nearby CPAN mirror, and included in Perl starting from the release 5.8.0.
 158  Or you may be able to use the following C<is_tainted()> function.
 160      sub is_tainted {
 161          return ! eval { eval("#" . substr(join("", @_), 0, 0)); 1 };
 162      }
 164  This function makes use of the fact that the presence of tainted data
 165  anywhere within an expression renders the entire expression tainted.  It
 166  would be inefficient for every operator to test every argument for
 167  taintedness.  Instead, the slightly more efficient and conservative
 168  approach is used that if any tainted value has been accessed within the
 169  same expression, the whole expression is considered tainted.
 171  But testing for taintedness gets you only so far.  Sometimes you have just
 172  to clear your data's taintedness.  Values may be untainted by using them
 173  as keys in a hash; otherwise the only way to bypass the tainting
 174  mechanism is by referencing subpatterns from a regular expression match.
 175  Perl presumes that if you reference a substring using $1, $2, etc., that
 176  you knew what you were doing when you wrote the pattern.  That means using
 177  a bit of thought--don't just blindly untaint anything, or you defeat the
 178  entire mechanism.  It's better to verify that the variable has only good
 179  characters (for certain values of "good") rather than checking whether it
 180  has any bad characters.  That's because it's far too easy to miss bad
 181  characters that you never thought of.
 183  Here's a test to make sure that the data contains nothing but "word"
 184  characters (alphabetics, numerics, and underscores), a hyphen, an at sign,
 185  or a dot.
 187      if ($data =~ /^([-\@\w.]+)$/) {
 188      $data = $1;             # $data now untainted
 189      } else {
 190      die "Bad data in '$data'";     # log this somewhere
 191      }
 193  This is fairly secure because C</\w+/> doesn't normally match shell
 194  metacharacters, nor are dot, dash, or at going to mean something special
 195  to the shell.  Use of C</.+/> would have been insecure in theory because
 196  it lets everything through, but Perl doesn't check for that.  The lesson
 197  is that when untainting, you must be exceedingly careful with your patterns.
 198  Laundering data using regular expression is the I<only> mechanism for
 199  untainting dirty data, unless you use the strategy detailed below to fork
 200  a child of lesser privilege.
 202  The example does not untaint C<$data> if C<use locale> is in effect,
 203  because the characters matched by C<\w> are determined by the locale.
 204  Perl considers that locale definitions are untrustworthy because they
 205  contain data from outside the program.  If you are writing a
 206  locale-aware program, and want to launder data with a regular expression
 207  containing C<\w>, put C<no locale> ahead of the expression in the same
 208  block.  See L<perllocale/SECURITY> for further discussion and examples.
 210  =head2 Switches On the "#!" Line
 212  When you make a script executable, in order to make it usable as a
 213  command, the system will pass switches to perl from the script's #!
 214  line.  Perl checks that any command line switches given to a setuid
 215  (or setgid) script actually match the ones set on the #! line.  Some
 216  Unix and Unix-like environments impose a one-switch limit on the #!
 217  line, so you may need to use something like C<-wU> instead of C<-w -U>
 218  under such systems.  (This issue should arise only in Unix or
 219  Unix-like environments that support #! and setuid or setgid scripts.)
 221  =head2 Taint mode and @INC
 223  When the taint mode (C<-T>) is in effect, the "." directory is removed
 224  from C<@INC>, and the environment variables C<PERL5LIB> and C<PERLLIB>
 225  are ignored by Perl. You can still adjust C<@INC> from outside the
 226  program by using the C<-I> command line option as explained in
 227  L<perlrun>. The two environment variables are ignored because
 228  they are obscured, and a user running a program could be unaware that
 229  they are set, whereas the C<-I> option is clearly visible and
 230  therefore permitted.
 232  Another way to modify C<@INC> without modifying the program, is to use
 233  the C<lib> pragma, e.g.:
 235    perl -Mlib=/foo program
 237  The benefit of using C<-Mlib=/foo> over C<-I/foo>, is that the former
 238  will automagically remove any duplicated directories, while the later
 239  will not.
 241  Note that if a tainted string is added to C<@INC>, the following
 242  problem will be reported:
 244    Insecure dependency in require while running with -T switch
 246  =head2 Cleaning Up Your Path
 248  For "Insecure C<$ENV{PATH}>" messages, you need to set C<$ENV{'PATH'}> to
 249  a known value, and each directory in the path must be absolute and
 250  non-writable by others than its owner and group.  You may be surprised to
 251  get this message even if the pathname to your executable is fully
 252  qualified.  This is I<not> generated because you didn't supply a full path
 253  to the program; instead, it's generated because you never set your PATH
 254  environment variable, or you didn't set it to something that was safe.
 255  Because Perl can't guarantee that the executable in question isn't itself
 256  going to turn around and execute some other program that is dependent on
 257  your PATH, it makes sure you set the PATH.
 259  The PATH isn't the only environment variable which can cause problems.
 260  Because some shells may use the variables IFS, CDPATH, ENV, and
 261  BASH_ENV, Perl checks that those are either empty or untainted when
 262  starting subprocesses. You may wish to add something like this to your
 263  setid and taint-checking scripts.
 265      delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};   # Make %ENV safer
 267  It's also possible to get into trouble with other operations that don't
 268  care whether they use tainted values.  Make judicious use of the file
 269  tests in dealing with any user-supplied filenames.  When possible, do
 270  opens and such B<after> properly dropping any special user (or group!)
 271  privileges. Perl doesn't prevent you from opening tainted filenames for reading,
 272  so be careful what you print out.  The tainting mechanism is intended to
 273  prevent stupid mistakes, not to remove the need for thought.
 275  Perl does not call the shell to expand wild cards when you pass C<system>
 276  and C<exec> explicit parameter lists instead of strings with possible shell
 277  wildcards in them.  Unfortunately, the C<open>, C<glob>, and
 278  backtick functions provide no such alternate calling convention, so more
 279  subterfuge will be required.
 281  Perl provides a reasonably safe way to open a file or pipe from a setuid
 282  or setgid program: just create a child process with reduced privilege who
 283  does the dirty work for you.  First, fork a child using the special
 284  C<open> syntax that connects the parent and child by a pipe.  Now the
 285  child resets its ID set and any other per-process attributes, like
 286  environment variables, umasks, current working directories, back to the
 287  originals or known safe values.  Then the child process, which no longer
 288  has any special permissions, does the C<open> or other system call.
 289  Finally, the child passes the data it managed to access back to the
 290  parent.  Because the file or pipe was opened in the child while running
 291  under less privilege than the parent, it's not apt to be tricked into
 292  doing something it shouldn't.
 294  Here's a way to do backticks reasonably safely.  Notice how the C<exec> is
 295  not called with a string that the shell could expand.  This is by far the
 296  best way to call something that might be subjected to shell escapes: just
 297  never call the shell at all.  
 299          use English '-no_match_vars';
 300          die "Can't fork: $!" unless defined($pid = open(KID, "-|"));
 301          if ($pid) {           # parent
 302              while (<KID>) {
 303                  # do something
 304              }
 305              close KID;
 306          } else {
 307              my @temp     = ($EUID, $EGID);
 308              my $orig_uid = $UID;
 309              my $orig_gid = $GID;
 310              $EUID = $UID;
 311              $EGID = $GID;
 312              # Drop privileges
 313              $UID  = $orig_uid;
 314              $GID  = $orig_gid;
 315              # Make sure privs are really gone
 316              ($EUID, $EGID) = @temp;
 317              die "Can't drop privileges"
 318                  unless $UID == $EUID  && $GID eq $EGID;
 319              $ENV{PATH} = "/bin:/usr/bin"; # Minimal PATH.
 320          # Consider sanitizing the environment even more.
 321              exec 'myprog', 'arg1', 'arg2'
 322                  or die "can't exec myprog: $!";
 323          }
 325  A similar strategy would work for wildcard expansion via C<glob>, although
 326  you can use C<readdir> instead.
 328  Taint checking is most useful when although you trust yourself not to have
 329  written a program to give away the farm, you don't necessarily trust those
 330  who end up using it not to try to trick it into doing something bad.  This
 331  is the kind of security checking that's useful for set-id programs and
 332  programs launched on someone else's behalf, like CGI programs.
 334  This is quite different, however, from not even trusting the writer of the
 335  code not to try to do something evil.  That's the kind of trust needed
 336  when someone hands you a program you've never seen before and says, "Here,
 337  run this."  For that kind of safety, check out the Safe module,
 338  included standard in the Perl distribution.  This module allows the
 339  programmer to set up special compartments in which all system operations
 340  are trapped and namespace access is carefully controlled.
 342  =head2 Security Bugs
 344  Beyond the obvious problems that stem from giving special privileges to
 345  systems as flexible as scripts, on many versions of Unix, set-id scripts
 346  are inherently insecure right from the start.  The problem is a race
 347  condition in the kernel.  Between the time the kernel opens the file to
 348  see which interpreter to run and when the (now-set-id) interpreter turns
 349  around and reopens the file to interpret it, the file in question may have
 350  changed, especially if you have symbolic links on your system.
 352  Fortunately, sometimes this kernel "feature" can be disabled.
 353  Unfortunately, there are two ways to disable it.  The system can simply
 354  outlaw scripts with any set-id bit set, which doesn't help much.
 355  Alternately, it can simply ignore the set-id bits on scripts.  If the
 356  latter is true, Perl can emulate the setuid and setgid mechanism when it
 357  notices the otherwise useless setuid/gid bits on Perl scripts.  It does
 358  this via a special executable called F<suidperl> that is automatically
 359  invoked for you if it's needed.
 361  However, if the kernel set-id script feature isn't disabled, Perl will
 362  complain loudly that your set-id script is insecure.  You'll need to
 363  either disable the kernel set-id script feature, or put a C wrapper around
 364  the script.  A C wrapper is just a compiled program that does nothing
 365  except call your Perl program.   Compiled programs are not subject to the
 366  kernel bug that plagues set-id scripts.  Here's a simple wrapper, written
 367  in C:
 369      #define REAL_PATH "/path/to/script"
 370      main(ac, av)
 371      char **av;
 372      {
 373      execv(REAL_PATH, av);
 374      }
 376  Compile this wrapper into a binary executable and then make I<it> rather
 377  than your script setuid or setgid.
 379  In recent years, vendors have begun to supply systems free of this
 380  inherent security bug.  On such systems, when the kernel passes the name
 381  of the set-id script to open to the interpreter, rather than using a
 382  pathname subject to meddling, it instead passes I</dev/fd/3>.  This is a
 383  special file already opened on the script, so that there can be no race
 384  condition for evil scripts to exploit.  On these systems, Perl should be
 385  compiled with C<-DSETUID_SCRIPTS_ARE_SECURE_NOW>.  The F<Configure>
 386  program that builds Perl tries to figure this out for itself, so you
 387  should never have to specify this yourself.  Most modern releases of
 388  SysVr4 and BSD 4.4 use this approach to avoid the kernel race condition.
 390  Prior to release 5.6.1 of Perl, bugs in the code of F<suidperl> could
 391  introduce a security hole.
 393  =head2 Protecting Your Programs
 395  There are a number of ways to hide the source to your Perl programs,
 396  with varying levels of "security".
 398  First of all, however, you I<can't> take away read permission, because
 399  the source code has to be readable in order to be compiled and
 400  interpreted.  (That doesn't mean that a CGI script's source is
 401  readable by people on the web, though.)  So you have to leave the
 402  permissions at the socially friendly 0755 level.  This lets 
 403  people on your local system only see your source.
 405  Some people mistakenly regard this as a security problem.  If your program does
 406  insecure things, and relies on people not knowing how to exploit those
 407  insecurities, it is not secure.  It is often possible for someone to
 408  determine the insecure things and exploit them without viewing the
 409  source.  Security through obscurity, the name for hiding your bugs
 410  instead of fixing them, is little security indeed.
 412  You can try using encryption via source filters (Filter::* from CPAN,
 413  or Filter::Util::Call and Filter::Simple since Perl 5.8).
 414  But crackers might be able to decrypt it.  You can try using the byte
 415  code compiler and interpreter described below, but crackers might be
 416  able to de-compile it.  You can try using the native-code compiler
 417  described below, but crackers might be able to disassemble it.  These
 418  pose varying degrees of difficulty to people wanting to get at your
 419  code, but none can definitively conceal it (this is true of every
 420  language, not just Perl).
 422  If you're concerned about people profiting from your code, then the
 423  bottom line is that nothing but a restrictive licence will give you
 424  legal security.  License your software and pepper it with threatening
 425  statements like "This is unpublished proprietary software of XYZ Corp.
 426  Your access to it does not give you permission to use it blah blah
 427  blah."  You should see a lawyer to be sure your licence's wording will
 428  stand up in court.
 430  =head2 Unicode
 432  Unicode is a new and complex technology and one may easily overlook
 433  certain security pitfalls.  See L<perluniintro> for an overview and
 434  L<perlunicode> for details, and L<perlunicode/"Security Implications
 435  of Unicode"> for security implications in particular.
 437  =head2 Algorithmic Complexity Attacks
 439  Certain internal algorithms used in the implementation of Perl can
 440  be attacked by choosing the input carefully to consume large amounts
 441  of either time or space or both.  This can lead into the so-called
 442  I<Denial of Service> (DoS) attacks.
 444  =over 4
 446  =item *
 448  Hash Function - the algorithm used to "order" hash elements has been
 449  changed several times during the development of Perl, mainly to be
 450  reasonably fast.  In Perl 5.8.1 also the security aspect was taken
 451  into account.
 453  In Perls before 5.8.1 one could rather easily generate data that as
 454  hash keys would cause Perl to consume large amounts of time because
 455  internal structure of hashes would badly degenerate.  In Perl 5.8.1
 456  the hash function is randomly perturbed by a pseudorandom seed which
 457  makes generating such naughty hash keys harder.
 458  See L<perlrun/PERL_HASH_SEED> for more information.
 460  The random perturbation is done by default but if one wants for some
 461  reason emulate the old behaviour one can set the environment variable
 462  PERL_HASH_SEED to zero (or any other integer).  One possible reason
 463  for wanting to emulate the old behaviour is that in the new behaviour
 464  consecutive runs of Perl will order hash keys differently, which may
 465  confuse some applications (like Data::Dumper: the outputs of two
 466  different runs are no more identical).
 468  B<Perl has never guaranteed any ordering of the hash keys>, and the
 469  ordering has already changed several times during the lifetime of
 470  Perl 5.  Also, the ordering of hash keys has always been, and
 471  continues to be, affected by the insertion order.
 473  Also note that while the order of the hash elements might be
 474  randomised, this "pseudoordering" should B<not> be used for
 475  applications like shuffling a list randomly (use List::Util::shuffle()
 476  for that, see L<List::Util>, a standard core module since Perl 5.8.0;
 477  or the CPAN module Algorithm::Numerical::Shuffle), or for generating
 478  permutations (use e.g. the CPAN modules Algorithm::Permute or
 479  Algorithm::FastPermute), or for any cryptographic applications.
 481  =item *
 483  Regular expressions - Perl's regular expression engine is so called NFA
 484  (Non-deterministic Finite Automaton), which among other things means that
 485  it can rather easily consume large amounts of both time and space if the
 486  regular expression may match in several ways.  Careful crafting of the
 487  regular expressions can help but quite often there really isn't much
 488  one can do (the book "Mastering Regular Expressions" is required
 489  reading, see L<perlfaq2>).  Running out of space manifests itself by
 490  Perl running out of memory.
 492  =item *
 494  Sorting - the quicksort algorithm used in Perls before 5.8.0 to
 495  implement the sort() function is very easy to trick into misbehaving
 496  so that it consumes a lot of time.  Nothing more is required than
 497  resorting a list already sorted.  Starting from Perl 5.8.0 a different
 498  sorting algorithm, mergesort, is used.  Mergesort is insensitive to
 499  its input data, so it cannot be similarly fooled.
 501  =back
 503  See L<http://www.cs.rice.edu/~scrosby/hash/> for more information,
 504  and any computer science textbook on the algorithmic complexity.
 506  =head1 SEE ALSO
 508  L<perlrun> for its description of cleaning up environment variables.

Generated: Tue Mar 17 22:47:18 2015 Cross-referenced by PHPXref 0.7.1