Perl, in all supported versions, has a problem with its handling of ambiguous
environments -- that is, when envp has two entries for a single variable name.
Perl provides a Perl-space hash variable, %ENV, in which environment variables
can be looked up. If variable "X" appears twice in envp, only the last value
would appear in %ENV, but getenv would return the first. Perl's "taint"
security mechanism would be applied to the value in %ENV, but not to other
the rest of the environment. This could result in an ambiguous environment
causing environment variables to be propagated to subprocesses, despite the
protections supposedly offered by taint checking.
With the attached patches, suitable for all supported versions of perl:
a) %ENV is populated with the first env var, as getenv would return
b) duplicate environment entries are removed
These patches will be applied to the public Perl source repository on Tuesday,
Created attachment 1127889 [details]
Created attachment 1127890 [details]
second VMS patch
Created perl tracking bugs for this issue:
Affects: fedora-all [bug 1313702]
perl-5.22.1-351.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Name: Stephane Chazelas
perl-5.20.3-329.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Resolution: --- → WONTFIX
It's not uncommon for us to close security issues as WONTFIX if we
think that they're not critical enough to warrant an immediate security
The main reason for closing this particular issue as WONTFIX is that
we are currently not aware of an application that would provide a
suitable attack vector. Without an application providing a suitable
method of exploitation that would result in the crossing of security
boundaries, the impact of this flaw is rather limited.
Just as an additionally note: this sort of problem has been documented
for almost two decades now. For example, the O'Reilly book "Practical
UNIX and Internet Security" already mentioned this back in 1996.
If you can provide us with additional information, concerns or further
questions, you are welcome to contact us via email@example.com