home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / man / cat.1 / perlsec.1 < prev    next >
Encoding:
Text File  |  1995-07-26  |  8.6 KB  |  199 lines
  1.  
  2.  
  3.  
  4.      PPPPEEEERRRRLLLLSSSSEEEECCCC((((1111))))  UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeelllleeeeaaaasssseeee 0000....0000 PPPPaaaattttcccchhhhlllleeeevvvveeeellll 00000000))))  PPPPEEEERRRRLLLLSSSSEEEECCCC((((1111))))
  5.  
  6.  
  7.  
  8.      NNNNAAAAMMMMEEEE
  9.           perlsec - Perl security
  10.  
  11.      DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  12.           Perl is designed to make it easy to write secure setuid and
  13.           setgid scripts.  Unlike shells, which are based on multiple
  14.           substitution passes on each line of the script, Perl uses a
  15.           more conventional evaluation scheme with fewer hidden
  16.           "gotchas".  Additionally, since the language has more
  17.           built-in functionality, it has to rely less upon external
  18.           (and possibly untrustworthy) programs to accomplish its
  19.           purposes.
  20.  
  21.           Beyond the obvious problems that stem from giving special
  22.           privileges to such flexible systems as scripts, on many
  23.           operating systems, setuid scripts are inherently insecure
  24.           right from the start.  This is because that between the time
  25.           that the kernel opens up the file to see what to run, and
  26.           when the now setuid interpreter it ran turns around and
  27.           reopens the file so it can interpret it, things may have
  28.           changed, especially if you have symbolic links on your
  29.           system.
  30.  
  31.           Fortunately, sometimes this kernel "feature" can be
  32.           disabled.  Unfortunately, there are two ways to disable it.
  33.           The system can simply outlaw scripts with the setuid bit
  34.           set, which doesn't help much.  Alternately, it can simply
  35.           ignore the setuid bit on scripts.  If the latter is true,
  36.           Perl can emulate the setuid and setgid mechanism when it
  37.           notices the otherwise useless setuid/gid bits on Perl
  38.           scripts.  It does this via a special executable called
  39.           ssssuuuuiiiiddddppppeeeerrrrllll that is automatically invoked for you if it's
  40.           needed.
  41.  
  42.           If, however, the kernel setuid script feature isn't
  43.           disabled, Perl will complain loudly that your setuid script
  44.           is insecure.  You'll need to either disable the kernel
  45.           setuid script feature, or put a C wrapper around the script.
  46.           See the program wwwwrrrraaaappppssssuuuuiiiidddd in the _e_g directory of your Perl
  47.           distribution for how to go about doing this.
  48.  
  49.           There are some systems on which setuid scripts are free of
  50.           this inherent security bug.  For example, recent releases of
  51.           Solaris are like this.  On such systems, when the kernel
  52.           passes the name of the setuid script to open to the
  53.           interpreter, rather than using a pathname subject to
  54.           mettling, it instead passes /dev/fd/3.  This is a special
  55.           file already opened on the script, so that there can be no
  56.           race condition for evil scripts to exploit.  On these
  57.           systems, Perl should be compiled with
  58.           -DSETUID_SCRIPTS_ARE_SECURE_NOW.  The CCCCoooonnnnffffiiiigggguuuurrrreeee program that
  59.           builds Perl tries to figure this out for itself.
  60.  
  61.  
  62.  
  63.      Page 1                                          (printed 6/30/95)
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.      PPPPEEEERRRRLLLLSSSSEEEECCCC((((1111))))  UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeelllleeeeaaaasssseeee 0000....0000 PPPPaaaattttcccchhhhlllleeeevvvveeeellll 00000000))))  PPPPEEEERRRRLLLLSSSSEEEECCCC((((1111))))
  71.  
  72.  
  73.  
  74.           When Perl is executing a setuid script, it takes special
  75.           precautions to prevent you from falling into any obvious
  76.           traps.  (In some ways, a Perl script is more secure than the
  77.           corresponding C program.)  Any command line argument,
  78.           environment variable, or input is marked as "tainted", and
  79.           may not be used, directly or indirectly, in any command that
  80.           invokes a subshell, or in any command that modifies files,
  81.           directories, or processes.  Any variable that is set within
  82.           an expression that has previously referenced a tainted value
  83.           also becomes tainted (even if it is logically impossible for
  84.           the tainted value to influence the variable).  For example:
  85.  
  86.               $foo = shift;               # $foo is tainted
  87.               $bar = $foo,'bar';          # $bar is also tainted
  88.               $xxx = <>;                  # Tainted
  89.               $path = $ENV{'PATH'};       # Tainted, but see below
  90.               $abc = 'abc';               # Not tainted
  91.  
  92.               system "echo $foo";         # Insecure
  93.               system "/bin/echo", $foo;   # Secure (doesn't use sh)
  94.               system "echo $bar";         # Insecure
  95.               system "echo $abc";         # Insecure until PATH set
  96.  
  97.               $ENV{'PATH'} = '/bin:/usr/bin';
  98.               $ENV{'IFS'} = '' if $ENV{'IFS'} ne '';
  99.  
  100.               $path = $ENV{'PATH'};       # Not tainted
  101.               system "echo $abc";         # Is secure now!
  102.  
  103.               open(FOO,"$foo");           # OK
  104.               open(FOO,">$foo");          # Not OK
  105.  
  106.               open(FOO,"echo $foo|");     # Not OK, but...
  107.               open(FOO,"-|") || exec 'echo', $foo;        # OK
  108.  
  109.               $zzz = `echo $foo`;         # Insecure, zzz tainted
  110.  
  111.               unlink $abc,$foo;           # Insecure
  112.               umask $foo;                 # Insecure
  113.  
  114.               exec "echo $foo";           # Insecure
  115.               exec "echo", $foo;          # Secure (doesn't use sh)
  116.               exec "sh", '-c', $foo;      # Considered secure, alas
  117.  
  118.           The taintedness is associated with each scalar value, so
  119.           some elements of an array can be tainted, and others not.
  120.  
  121.           If you try to do something insecure, you will get a fatal
  122.           error saying something like "Insecure dependency" or
  123.           "Insecure PATH".  Note that you can still write an insecure
  124.           system call or exec, but only by explicitly doing something
  125.           like the last example above.  You can also bypass the
  126.  
  127.  
  128.  
  129.      Page 2                                          (printed 6/30/95)
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.      PPPPEEEERRRRLLLLSSSSEEEECCCC((((1111))))  UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((RRRReeeelllleeeeaaaasssseeee 0000....0000 PPPPaaaattttcccchhhhlllleeeevvvveeeellll 00000000))))  PPPPEEEERRRRLLLLSSSSEEEECCCC((((1111))))
  137.  
  138.  
  139.  
  140.           tainting mechanism by referencing subpatterns--Perl presumes
  141.           that if you reference a substring using $1, $2, etc, you
  142.           knew what you were doing when you wrote the pattern:
  143.  
  144.               $ARGV[0] =~ /^-P(\w+)$/;
  145.               $printer = $1;              # Not tainted
  146.  
  147.           This is fairly secure since \w+ doesn't match shell
  148.           metacharacters.  Use of /.+/ would have been insecure, but
  149.           Perl doesn't check for that, so you must be careful with
  150.           your patterns.  This is the _O_N_L_Y mechanism for untainting
  151.           user supplied filenames if you want to do file operations on
  152.           them (unless you make $> equal to $< ).
  153.  
  154.           For "Insecure PATH" messages, you need to set $ENV{'PATH}'
  155.           to a known value, and each directory in the path must be
  156.           non-writable by the world.  A frequently voiced gripe is
  157.           that you can get this message even if the pathname to an
  158.           executable is fully qualified.  But Perl can't know that the
  159.           executable in question isn't going to execute some other
  160.           program depending on the PATH.
  161.  
  162.           It's also possible to get into trouble with other operations
  163.           that don't care whether they use tainted values.  Make
  164.           judicious use of the file tests in dealing with any user-
  165.           supplied filenames.  When possible, do opens and such after
  166.           setting $> = $<.  (Remember group IDs, too!) Perl doesn't
  167.           prevent you from opening tainted filenames for reading, so
  168.           be careful what you print out.  The tainting mechanism is
  169.           intended to prevent stupid mistakes, not to remove the need
  170.           for thought.
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.      Page 3                                          (printed 6/30/95)
  196.  
  197.  
  198.  
  199.