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

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

Thread Previous | Thread Next
Rafael Garcia-Suarez
October 26, 2003 15:20
Re: [perl #24291] Taint checking against the wrong environment
Message ID: wrote:
> Ouch. I note that also if the new %ENV includes a PATH I get a
> coredump instead:
> perl -Twe '%a=(PATH=>"util"); *ENV=\%a; system("echo unsafe")'
> Segmentation fault (core dumped)
> zen% 
> #0  Perl_mg_find (sv=0x814dee0, type=101) at mg.c:327
> #1  0x081129f3 in Perl_taint_env () at taint.c:116
> #2  0x080f96a7 in Perl_pp_system () at pp_sys.c:4076
> [..]
> I believe this is happening because mg_find() assumes it will never
> be called with an SV that isn't magical, and taint_env() assumes
> that anything pulled out of %ENV will always have magic attached.

That's correct, and I fixed the coredump case by change #21542.
$ENV{PATH} is still checked for taintedness when %ENV is aliased to
another hash, although this might be a bit futile in this situation.

> The main question I think is what C< *ENV = \%myenv > should mean:
> either it should act to replace the environment or not, and the
> rest of the core should act appropriately either way. I think in
> principle it would be most useful for it to replace the environment,
> but I accept that that involves a lot of extra code and could also
> make C< *ENV = \%myenv > unexpectedly slow. This implies that eg
> C< local %ENV = ( PATH => $path ) > should also work.
> (Hmm, can we even tell? C< *ENV = \*A; *A = \%myenv > may make
> things tricky.)

Maybe do nothing and let people shoot in their feet.

Maybe just forbid aliasing *ENV at all. (with the collateral damage
on $ENV etc.) (or couldn't this chained alias thing be solved
by looking at the GvEGV ?)

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