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

[Sa...@barclayscapital.com]

 Hello All,

> -----Original Message-----
> From: Shah, Sagar: IT (LDN) 
> Sent: 17 April 2007 09:39
> To: 'Charlie Katz'; modperl@perl.apache.org
> Cc: Perrin Harkins; clint@traveljury.com; rlandrum@aol.net; 
> Client Research Development
> Subject: RE: "Insecure dependency in eval while running setgid" error
> 
> Hi Charlie, 
> 
> > -----Original Message-----
> > From: Charlie Katz [mailto:ckatz@cfa.harvard.edu] 
> > Sent: 30 March 2007 19:00
> > To: modperl@perl.apache.org
> > Cc: Perrin Harkins; Shah, Sagar: IT (LDN); 
> > clint@traveljury.com; rlandrum@aol.net; Client Research Development
> > Subject: Re: "Insecure dependency in eval while running 
> setgid" error
> > 
> > Hi All,
> > 
> > I've been following this discussion closely because I had 
> > what seems to be the 
> > same problem Sagar is having.
> > 
> > On Friday 30 March 2007 12:19 pm, Perrin Harkins wrote:
> > > 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 was initially on-board with Sagar about this being a 
> > taint-checker problem, 
> > but Perrin's makes a pretty good point: it *is* rather 
> > suggestive that the 
> > insecure dependency message refers to "while running setgid" 
> > at the same time 
> > that the server reports GID-EGID mismatch due to a 
> > nonsensical EGID.  I 
> > checked and found that my server displays the EGID problem as 
> > well, so 
> > decided to take Perrin's advice and investigate this first.
> > 
> > I ran ps, which showed that the httpd processes all have 
> > their GID matching 
> > their EGID.  Then I checked in perl by reporting the GID and 
> > EGID from the 
> > parent and children and found that the nonsensical EGID 
> > appears in the 
> > children when they are spawned (or at least in the 
> > PerlChildInitHandler). 
> > This seems to localize the problem to mod_perl.
> > 
> > I started greping around in the mod_perl source code (I have 
> > 2.0.2) and found 
> > this in modperl_perl.c:
> > 
> > --------------------------------------------------------------
> > ------------------------------
> > static void modperl_perl_ids_get(modperl_perl_ids_t *ids)
> > {
> >     ids->pid  = (I32)getpid();
> > #ifdef MP_MAINTAIN_PPID
> >     ids->ppid = (I32)getppid();
> > #endif
> > #ifndef WIN32
> >     ids->uid  = getuid();
> >     ids->euid = geteuid(); 
> >     ids->gid  = getgid(); 
> >     ids->gid  = getegid(); 
> > --------------------------------------------------------------
> > ------------------------------
> > I changed that last line to
> > 
> >    ids->egid = getegid();
> > 
> > then rebuilt/reinstalled/restarted, and the EGID problem is gone.  
> > 
> > I checked the 2.0.3 source and found this already fixed there.
> > 
> > 
> > 
> > Sagar, can you try the same thing with your server?  Perhaps 
> > the "tainting" 
> > problem will just disappear once this bug is fixed.
> 
> 
> Sorry for the delayed reply, I had been on leave and had 
> asked the other members of my team to continue to look into 
> this and feed back to the list, but as soon as they had 
> started looking into the issue they were asked to work on 
> something higher priority ;-)
> 
> As Fred said, great catch.
> 
> The initial feeling in our team was that because we're 
> explicitly switching taint mode on all this fix will do is 
> change the error message from "in eval while running setgid" 
> to something else as per the if/else block in taint.c.   That 
> said given that there was quite a gap between 2.0.2 and 2.0.3 
> I think your suggestion is still worth trying. This or other 
> fixes might indirectly resolve the issue and it's always best 
> practice to try and repeat what appears to be a bug against 
> the latest version of the software. The only reason we held 
> off from doing this initially was that there wasn't anything 
> in the changes file that seemed connected, but as you've 
> shown there are other smaller changes included also.
> 
> I'll report back with how I get on.

It's been a while and we've been hacking away at the issue so I thought I'd report back to the list now that we've finally got to the bottom of it.

Rather than upgrading to mod_perl 2.0.3 straight away we thought we'd first try and create a smaller test case by hacking away at the code we started with and taking the good old 'binary chop' approach. We eventually found that we were able to repeat the problem in a perl script outside mod_perl so I can clearly state that this problem was not caused by a mod_perl bug.

We continued to work on our test case removing all reference to our own applications code and then stripping down any CPAN modules that the code referenced. We were eventaully able to get to the following test case which implied there was some bug in perl:

---code---
#!/opt/perl586/bin/perl -T

# pragmata
use strict;
use warnings;
use utf8;

 
# This line of code is based upon the decalaration of the NoTaint package
# variable in Date::Manip Template::Plugin::Date does a require of
# 'Date::Manip' rather than a use.  This change in the execution order does
# indeed makes a difference of whether the bug occurs or not.

# $ENV{HOME} is tainted, so the internal eval fails, and the external eval just
# hides that, so it shouldn't have any ongoing effects
eval { eval "#" . $ENV{HOME} };
  
# This section of code is based upon us orginally getting a data structure back
# from XML::Simple and passing its values to our Template Toolkit template that
# involved Date::Manip::UnixDate via Template::Plugin::Date. The value in the
# datastructure from XML::Simple was utf8-tagged. The lowercasing of the result
# of a pattern match comes from Date::Manip::ParseDateString.

# do an lc on a $1 captured from a match on a utf8-tagged variable
# (assigning to $throwaway just suppresses a warning)
my $d = ' ';
utf8::upgrade($d);
$d =~ /(.)/;
my $throwaway = lc $1;


# This section just demonstrates the bug occcuring once the above operations
# have somehow  'corrupted' the internal state within Perl. In our application
# it was Template::Document where we had the regex and eval occuring

# get a tainted value fromt the environment
my $home = $ENV{HOME};
$home =~ /(.*)/;
  
# assing $1 back to the variable the match was done on - the new value of
# $home therefore should not be tainted....
$home = $1;

# ...but it is
eval "print \"$home\\n\";";
---code---

We are currently using perl 5.8.6 and we could repeat the problem under perl 5.8.7 but not under perl 5.8.8 so it definitely seems that the underlying bug has been fixed. Hopefully this is useful information to archive on the mailing list. If someone gets similar behaviour in the future they should be able to workaround the bug with their current perl and eliminate it completely by upgrading.

I just wanted to say thanks again to everyone that's contributed to the thread. Your support gave us the courage and direction to get to the bottom of the issue.

Regards

Sagar


=ANYTING+BELOW+THIS+LINE+WAS+ADDED+AFTER+I+HIT+SEND=
------------------------------------------------------------------------
For important statutory and regulatory disclosures and 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.

Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
------------------------------------------------------------------------