develooper Front page | perl.perl5.porters | Postings from October 2003

Re: [perl #24291] Taint checking against the wrong environment

Thread Previous
October 26, 2003 06:25
Re: [perl #24291] Taint checking against the wrong environment
Message ID:
In article <20031026130818.430969_4.rgarciasuarez@_ree._r>,
	Rafael Garcia-Suarez <> writes:
> I recently documented in perlsub that C<local *foo> doesn't preserve
> magic on $foo, @foo, %foo etc. (perlsub/"Localization of globs").
> This feature can be useful when doing C<local *_> in order to
> localize $_ _and_ drop all previous magic on $_ that might get in
> the way. In other words, C<local %ENV> allows to modify the environment,
> while C<local *ENV> does not.
> Considering this, I think that a glob assignment to *ENV should drop
> the env magic from it, and that the core must be fixed to deal with
> it gracefully. That's more consistent with the rest of perl (and the
> rest of magical variables.)

What I had expected to happen is that perl internally has a reference
to the "real" magic env hash, and that my local *ENV = $hash_ref indeed
would replace the the HASH slot in *ENV with my new reference, but that
the real magic env keeps pointing to the old place. Then system/exec/qx
taint checks would still be done against against this preserved "real"
magic env. That would be enough to fix the security hole. The fact that
it's maybe unexpected that the real env isn't changed by local *ENV=$ref,
well, you can expect weird things if you write such weird code.

In my particular application I don't actually want all these setenv's to
happen on every little event. The only reason I set %ENV at all is to
make old CGI code happy. The only time I want the real env to change in
this application is when I'm indeed doing an external call, and I'm
prepared to do that "by hand" if needed.
void russian_roulette(void) { char *target; strcpy(target, "bullet"); }

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About