home *** CD-ROM | disk | FTP | other *** search
/ Geek Gadgets 1 / ADE-1.bin / ade-bin / lib / perl5 / pod / perlsec.pod < prev    next >
Encoding:
Text File  |  1996-10-09  |  6.6 KB  |  148 lines
  1. =head1 NAME
  2.  
  3. perlsec - Perl security
  4.  
  5. =head1 DESCRIPTION
  6.  
  7. Perl is designed to make it easy to write secure setuid and setgid
  8. scripts.  Unlike shells, which are based on multiple substitution
  9. passes on each line of the script, Perl uses a more conventional
  10. evaluation scheme with fewer hidden "gotchas".  Additionally, since the
  11. language has more built-in functionality, it has to rely less upon
  12. external (and possibly untrustworthy) programs to accomplish its
  13. purposes.
  14.  
  15. Beyond the obvious problems that stem from giving special privileges to
  16. such flexible systems as scripts, on many operating systems, setuid
  17. scripts are inherently insecure right from the start.  This is because
  18. that between the time that the kernel opens up the file to see what to
  19. run, and when the now setuid interpreter it ran turns around and reopens
  20. the file so it can interpret it, things may have changed, especially if
  21. you have symbolic links on your system.
  22.  
  23. Fortunately, sometimes this kernel "feature" can be disabled.
  24. Unfortunately, there are two ways to disable it.  The system can simply
  25. outlaw scripts with the setuid bit set, which doesn't help much.
  26. Alternately, it can simply ignore the setuid bit on scripts.  If the
  27. latter is true, Perl can emulate the setuid and setgid mechanism when it
  28. notices the otherwise useless setuid/gid bits on Perl scripts.  It does
  29. this via a special executable called B<suidperl> that is automatically
  30. invoked for you if it's needed.
  31.  
  32. If, however, the kernel setuid script feature isn't disabled, Perl will
  33. complain loudly that your setuid script is insecure.  You'll need to
  34. either disable the kernel setuid script feature, or put a C wrapper around
  35. the script.  See the program B<wrapsuid> in the F<eg> directory of your
  36. Perl distribution for how to go about doing this.
  37.  
  38. There are some systems on which setuid scripts are free of this inherent
  39. security bug.  For example, recent releases of Solaris are like this.  On
  40. such systems, when the kernel passes the name of the setuid script to open
  41. to the interpreter, rather than using a pathname subject to mettling, it
  42. instead passes /dev/fd/3.  This is a special file already opened on the
  43. script, so that there can be no race condition for evil scripts to
  44. exploit.  On these systems, Perl should be compiled with
  45. C<-DSETUID_SCRIPTS_ARE_SECURE_NOW>.  The B<Configure> program that builds
  46. Perl tries to figure this out for itself.
  47.  
  48. When executing a setuid script, or when you have turned on taint checking
  49. explicitly using the B<-T> flag, Perl takes special precautions to
  50. prevent you from falling into any obvious traps.  (In some ways, a Perl
  51. script is more secure than the corresponding C program.)  Any command line
  52. argument, environment variable, or input is marked as "tainted", and may
  53. not be used, directly or indirectly, in any command that invokes a
  54. subshell, or in any command that modifies files, directories, or
  55. processes.  Any variable that is set within an expression that has
  56. previously referenced a tainted value also becomes tainted (even if it is
  57. logically impossible for the tainted value to influence the variable).
  58. For example:
  59.  
  60.     $foo = shift;        # $foo is tainted
  61.     $bar = $foo,'bar';        # $bar is also tainted
  62.     $xxx = <>;            # Tainted
  63.     $path = $ENV{'PATH'};    # Tainted, but see below
  64.     $abc = 'abc';        # Not tainted
  65.  
  66.     system "echo $foo";        # Insecure
  67.     system "/bin/echo", $foo;    # Secure (doesn't use sh)
  68.     system "echo $bar";        # Insecure
  69.     system "echo $abc";        # Insecure until PATH set
  70.  
  71.     $ENV{'PATH'} = '/bin:/usr/bin';
  72.     $ENV{'IFS'} = '' if $ENV{'IFS'} ne '';
  73.  
  74.     $path = $ENV{'PATH'};    # Not tainted
  75.     system "echo $abc";        # Is secure now!
  76.  
  77.     open(FOO,"$foo");        # OK
  78.     open(FOO,">$foo");         # Not OK
  79.  
  80.     open(FOO,"echo $foo|");    # Not OK, but...
  81.     open(FOO,"-|") || exec 'echo', $foo;    # OK
  82.  
  83.     $zzz = `echo $foo`;        # Insecure, zzz tainted
  84.  
  85.     unlink $abc,$foo;        # Insecure
  86.     umask $foo;            # Insecure
  87.  
  88.     exec "echo $foo";        # Insecure
  89.     exec "echo", $foo;        # Secure (doesn't use sh)
  90.     exec "sh", '-c', $foo;    # Considered secure, alas
  91.  
  92. The taintedness is associated with each scalar value, so some elements
  93. of an array can be tainted, and others not.
  94.  
  95. If you try to do something insecure, you will get a fatal error saying
  96. something like "Insecure dependency" or "Insecure PATH".  Note that you
  97. can still write an insecure system call or exec, but only by explicitly
  98. doing something like the last example above.  You can also bypass the
  99. tainting mechanism by referencing subpatterns--Perl presumes that if
  100. you reference a substring using $1, $2, etc, you knew what you were
  101. doing when you wrote the pattern:
  102.  
  103.     $ARGV[0] =~ /^-P(\w+)$/;
  104.     $printer = $1;        # Not tainted
  105.  
  106. This is fairly secure since C<\w+> doesn't match shell metacharacters.
  107. Use of C</.+/> would have been insecure, but Perl doesn't check for that,
  108. so you must be careful with your patterns.  This is the I<ONLY> mechanism
  109. for untainting user supplied filenames if you want to do file operations
  110. on them (unless you make C<$E<gt>> equal to C<$E<lt>> ).
  111.  
  112. For "Insecure $ENV{PATH}" messages, you need to set C<$ENV{'PATH'}> to a known
  113. value, and each directory in the path must be non-writable by the world.
  114. A frequently voiced gripe is that you can get this message even
  115. if the pathname to an executable is fully qualified.  But Perl can't
  116. know that the executable in question isn't going to execute some other
  117. program depending on the PATH.
  118.  
  119. It's also possible to get into trouble with other operations that don't
  120. care whether they use tainted values.  Make judicious use of the file
  121. tests in dealing with any user-supplied filenames.  When possible, do
  122. opens and such after setting C<$E<gt> = $E<lt>>.  (Remember group IDs,
  123. too!) Perl doesn't prevent you from opening tainted filenames for reading,
  124. so be careful what you print out.  The tainting mechanism is intended to
  125. prevent stupid mistakes, not to remove the need for thought.
  126.  
  127. This gives us a reasonably safe way to open a file or pipe: just reset the
  128. id set to the original IDs.  Here's a way to do backticks reasonably
  129. safely.  Notice how the exec() is not called with a string that the shell
  130. could expand.  By the time we get to the exec(), tainting is turned off,
  131. however, so be careful what you call and what you pass it.
  132.  
  133.     die unless defined $pid = open(KID, "-|");
  134.     if ($pid) {              # parent
  135.     while (<KID>) {
  136.         # do something
  137.     } 
  138.     close KID;
  139.     } else {
  140.     $> = $<; 
  141.     $) = $(;  # BUG: initgroups() not called
  142.     exec 'program', 'arg1', 'arg2';
  143.     die "can't exec program: $!";
  144.     } 
  145.  
  146. For those even more concerned about safety, see the I<Safe> and I<Safe CGI> 
  147. modules at a CPAN site near you.  See L<perlmod> for a list of CPAN sites.
  148.