Hi All, I'm getting closer to this now...
> -----Original Message----- > From: Shah, Sagar: IT (LDN) > Sent: 29 March 2007 10:07 > To: 'Robert Landrum'; 'Perrin Harkins' > Cc: 'modperl@perl.apache.org' > Subject: RE: "Insecure dependency in eval while running setgid" error > > > > You could add: > > > > > > warn "BLOCK: $block\n"; > > > > > > just above the eval, which will log all the "blocks" that are > > > being eval > > > to figure out which one is giving you the trouble. > > > > That's a useful suggestion, I'll give that a try. What I'm > > expecting to find is that the $block that causes the error is > > identical to previous $block values which don't cause an > > error, but this will be a good thing to actually prove. > > > > Thanks very much. > > > My hypothesis was correct. The $block that causes the > Insecure Dependency error to be thrown is identical to > previous calls to that URL. > > Here's what $block contains: > > [snip] > > Can anyone spot something that would cause this to throw a > taint error (remember the $block string itself has been > untainted, altho I think I'll add some extra debugging to > confirm this as well). I addded two pieces of extra debugging. One to confirm that the $block value was always tainted before the regular expression /(.*)/ was applied and another to confirm whether or not it was tainted after the regular expression was applied. I was able to clearly prove that the code works as expected (value is tained before the regex and value is untainted after the assignemnt/before the eval) in the general case, but not occasionally: ==logs extract, sniped for other pids== The Block I'm just about to untaint in pid 11852 is initally tainted The Block I'm just about to eval in pid 11852 is not tainted The Block I'm just about to untaint in pid 11852 is initally tainted The Block I'm just about to eval in pid 11852 is not tainted The Block I'm just about to untaint in pid 11852 is initally tainted The Block I'm just about to eval in pid 11852 is tainted ==logs extract, sniped for other pids== It doesn't seem to be related to the parameters sent to the script at all, or the number of times the script hits the infected page. What I think I've now clearly proven is that after some point in time the perl interpreter loses it's ability to untaint variables via regular expressions (or to be specific the values of variables containting regex captured text is still tainted). As soon as this happens once the problem remains for the length of that child httpd process's life. Can anyone think of why this might happen? I know that Perl has a special case: if you 'use locale;' then character classes such as \w lose their ability to untaint because the local locale on the box is considered untrusted. I don't think this case applies here because a) The template toolkit developer hasn't used a character class b) use locale is not in play (I've gone as far as putting no locale in Template::Document). Are there any other cases? How does perl handle the special case above, is there some magical variable $let_regexes_have_the_untaint_power or something of that order (silly long shot I know) I have to say I'm finding it harder and harder to believe the issue is either with my own code or with the code of any of the CPAN modules I'm using. The suggestions from some people to just turn taint mode off in production make me wonder whether there's been enough real world use of taint mode in mod_perl2 to give it sufficient real world testing. I guess the next step is for me to try and produce a simpler test case, one that cuts out the functionality of this page itself and just shows a script that just does a regex untaint failing after repeated calls. As I have other taint related code that's been running under mod_perl fine, it's still unclear why it's this code that I'm first seeing the problem with. > Once a particular process produces this Insecure Dependency, > it seems that any future calls to that same process will also > produce the error. So again, it definitely looks like the > process is being corrupted in some way.... ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------
