inconsistent taint check results

[Charlie Katz <ck...@cfa.harvard.edu>]

Hi all,

The site I develop (Apache 2.2.3, mod_perl 2.0.2 [perl 5.8.5], Mason 1.33) 
runs with taint checking ("PerlSwitches -wT -I/www").  It's been working fine 
for many months now, with my scripts happily untainting variables as 
required.

In the last couple of weeks, all of a sudden I am seeing occasional and 
sporadic "Insecure dependency in XXX while running setgid" errors all around 
the site.  Seemingly important things I've observed about the errors:

-they seem to start after the server's been running for a day or two; 
restarting it makes them go away for a while

-inconsistent: after an occurence (which returns 500 to the client), simply 
hitting reload in the browser gets the same request answered successfully

-not process dependent: the reload is successful whether the request hits the 
same Apache child that previously had the error, or a different child

-nonsensical: one of the places I found it occurring is in a sysopen() using a 
variable which was explicitly untainted in the preceding two lines of code

-not limited to any particular script; when they happen, they can be anywhere 
in my code that taint checking matters


I've been doing a lot of development lately (in particular adding a CDBI based 
system), but these errors are occurring in scripts that haven't been touched 
in over a year.  

After some investigation, all I've learned is that perl definitely does think 
the variables are tainted (duh!).  I'm afraid I have little idea of what to 
do next.  Any suggested courses of inquiry I could take up would be greatly 
appreciated.

Regards,
Charlie

-- 
Charlie Katz
Harvard-Smithsonian Center for Astrophysics
ckatz@cfa.harvard.edu

Re: inconsistent taint check results

[Charlie Katz <ck...@cfa.harvard.edu>]

Well, I didn't get any replies to my question, so I kept poking around.  Since 
the problem seems to appear only after the server has been running for a 
while, seemingly can appear in any part of my system where taint checking 
matters, and produces nonsensical results, I wondered if perhaps something 
within perl's taint checking mechanism itself was getting corrupted.

Looking back through my notes, I remembered that when I had installed 
Taint-0.09 a number of tests had failed during "make test".  (my bad decision 
to use it like that)  Reading the "BUGS" section of the doc for that module 
put fear in my heart about taint checking (although the doc is 10 years old), 
so I stopped using it in my code. The server has been running for about a 
week now, and the problem hasn't reappeared. 

I guess all my new development tickled a problem that was already there.  Let 
that be a lesson to me. ;-)

Charlie Katz

On Wednesday 07 March 2007 12:27 pm, Charlie Katz wrote:
> Hi all,
>
> The site I develop (Apache 2.2.3, mod_perl 2.0.2 [perl 5.8.5], Mason 1.33)
> runs with taint checking ("PerlSwitches -wT -I/www").  It's been working
> fine for many months now, with my scripts happily untainting variables as
> required.
>
> In the last couple of weeks, all of a sudden I am seeing occasional and
> sporadic "Insecure dependency in XXX while running setgid" errors all
> around the site.  Seemingly important things I've observed about the
> errors:
>
> -they seem to start after the server's been running for a day or two;
> restarting it makes them go away for a while
>
> -inconsistent: after an occurence (which returns 500 to the client), simply
> hitting reload in the browser gets the same request answered successfully
>
> -not process dependent: the reload is successful whether the request hits
> the same Apache child that previously had the error, or a different child
>
> -nonsensical: one of the places I found it occurring is in a sysopen()
> using a variable which was explicitly untainted in the preceding two lines
> of code
>
> -not limited to any particular script; when they happen, they can be
> anywhere in my code that taint checking matters
>
>
> I've been doing a lot of development lately (in particular adding a CDBI
> based system), but these errors are occurring in scripts that haven't been
> touched in over a year.
>
> After some investigation, all I've learned is that perl definitely does
> think the variables are tainted (duh!).  I'm afraid I have little idea of
> what to do next.  Any suggested courses of inquiry I could take up would be
> greatly appreciated.
>
> Regards,
> Charlie

-- 
Charlie Katz
Harvard-Smithsonian Center for Astrophysics
ckatz@cfa.harvard.edu

authcookie/session

[jim booe <ji...@hotmail.com>]

Hi,

I've read through a lot of mailing list archives and the documentation for 
Apache2::AuthCookie and found that tying Apache2::AuthCookie with 
CGI::Session was exactly what I was looking for.

I'm running mp2/apache2...I've got things working, but I'd like to see if 
there's a better way.

In my AuthCookie sub class, I check my user credentials in authen_cred(). If 
I get a successful login, then I create a session with CGI::Session and 
return the generated session key.

sub authen_cred ($$\@) {
    my $self = shift;
    my $r = shift;
    my($username,$password) = @_;

    # Check user and create session if valid
    my $session = authenticate_user($username, $password);
    return $session;
}

sub authenticate_user {
    my($username,$password) = @_;

   # Check username/password in database
   # other code left out for clarity
   $s = CGI::Session->load() or die CGI::Session->errstr;
   # check that session was created here,
   # redirect to login if expired, $s->new if empty
   # if ok, return session id
  return $s->id();
}

In the various examples I've seen of AuthCookie (without 
Apache/CGI::Session), the session key is a ticket so you can tell if it's 
been tampered with or expired. Since I'm using CGI::Session to generate the 
key, I'm simply checking that the session key is valid in authen_ses_key() 
using the CGI::Session load($session_id) function:

my $s = CGI::Session->load($session) or die CGI::Session->errstr;

Which leads me to my second question - if I find that key is valid (in 
authen_ses_key), then I use pnotes to store a reference to my session, so I 
can access it later in a response handler - believe I saw mention of that 
and it seems to work, but verifying that's the best way.

Thanks all...
--
jb

_________________________________________________________________
With tax season right around the corner, make sure to follow these few 
simple tips. 
http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline