RE: "Insecure dependency in eval while running setgid" error

[<suppressed>]

> -----Original Message-----
> From: Perrin Harkins [mailto:suppressed 
> Sent: 30 March 2007 17:19
> To: Shah, Sagar: IT (LDN)
> Cc: suppressed; suppressed; 
> suppressed; Client Research Development
> Subject: Re: "Insecure dependency in eval while running setgid" error
> 
> 
> On 3/30/07, suppressed 
> <suppressed> wrote:
> > The untainting itself however happens just before the error 
> is thrown, 
> > so think it's more about estabilishing in precisely which 
> conditions 
> > the m// operator loses it's ability to untaint and coming 
> up with the 
> > most trivial demonstration of that we can.
> 
> This might be a silly question, but what makes you think this 
> has to do with tainting?  If it was a taint problem, wouldn't 
> it say "Insecure dependency in eval while running with -T 
> switch"?  It's complaining about eval while running setgid.  
> (I know you said you aren't running setgid, but I think you 
> should be trying to figure out why it thinks it's setgid, not 
> why something is tainted.)


I think the text of the error message is getting confused because perl
thinks it's running setgid when it isn't (that's a separate and less
important issue that I think a couple of people have pointed out to get
me on the right track). Earlier this week I and a colleage  were looking
at the perl code and I think the suffix of that error message is just
decided by a block of tests not by what rows the taint error.

The reason why I think it's an issue with tainting is simply because:
A) It's an Insecure Depdencency error
B) As I saw with the debugging output that I sent to the mailing list
yesterday, the time when it goes wrong is when the m/(.*)/ line doesn't
untaint a piece of text which it has untainted lots of times before just
fine. Surely that should be a deterministic and repeatable action. i.e.
the output should always be the same if the input is. (assuming
controlled conditions with the regex engine's options)

It's certainly not an error with the specific code that is being evaled
or anything that code is doing. I've convinced myself of that pretty
reasonably. The fact that I think I haven't hit the error before is that
using a piece of tainted data in most operations doesn't result in a
warning, it's only certain operations of which eval is one of.

On Monday we're going to see if we can repeat the problem in our other
mod_perl page just by adding some debugging to that to see if the stuff
we think we're successfully untainting is actually untainted  every
time, or only most of the time. This'll be an interesting thing to
report back on..

------------------------------------------------------------------------
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.
------------------------------------------------------------------------