> I need some help with this. Can you share the code you use w/in
> your <Perl> section?

  Sure! Here is how I untaint a selected range of variables from the
WWW server's %ENV, and discard all the others (good move to ease
debugging anyway):

   # From httpd.conf
   PerlTaintCheck On
   
   <perl>
      BEGIN {
           # Untaint environment. Those variables come from
           # Apache; even if they didn't, they would come from the root
           # user who launched Apache. No security problems here.
   
           my %cleanenv;
           foreach my $var (qw(PATH GATEWAY_INTERFACE MOD_PERL)) {
              ($cleanenv{$var})=($ENV{$var} =~ m/^(.*)$/g);
           }
           %ENV=%cleanenv;
       }   
   </perl>

> I'm pretty confused because I was able to untaint my PATH var.
> by putting 
> 
> $ENV{PATH} = '/bin';
> 
> in the ***same scope*** where I was getting the error.

 Makes sense to me: if you are using Apache::Registry (for example),
your script only gets compiled once and the BEGIN blocks run at that
time. In fact Apache::Registry reads your cgi, then cooks it into
something like this:

package Some::Name::Made::Up::By::Apache::Registry::To::Isolate::Your::cgi;

sub handler {
  # Your script here
}

  Then it evals that (by that time, the BEGIN blocks run), then calls
Some::Name::...::handler(). The purpose of these steps is caching: the
next time the CGI is hit, the evalling needs not be redone, only the
handler call.

  Now, my guess was that %ENV gets reset between the eval and the
handler call. As you mention, putting the untainter in the same scope
solves the problem, because you now circumvent the cleaning. Putting
it in the <perl> section should also solve the problem once for all,
because the <perl> section runs before the default %ENV value is
stashed (even before Apache forks, in fact).

-- 
Dominique QUATRAVAUX                           Ingénieur senior
01 44 42 00 08                                 IDEALX


Reply via email to