Bug 1309214 - (CVE-2016-2381) CVE-2016-2381 perl: ambiguous environment variables handling
CVE-2016-2381 perl: ambiguous environment variables handling
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20160301,repor...
: Security
Depends On: 1313702
Blocks: 1309216
  Show dependency treegraph
 
Reported: 2016-02-17 04:01 EST by Andrej Nemec
Modified: 2016-03-15 07:35 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-09 10:28:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
first patch (3.51 KB, patch)
2016-02-17 04:03 EST, Andrej Nemec
no flags Details | Diff
second VMS patch (921 bytes, patch)
2016-02-17 04:03 EST, Andrej Nemec
no flags Details | Diff

  None (edit)
Description Andrej Nemec 2016-02-17 04:01:59 EST
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

Unembargo date:

These patches will be applied to the public Perl source repository on Tuesday,
March 1.
Comment 1 Andrej Nemec 2016-02-17 04:03 EST
Created attachment 1127889 [details]
first patch
Comment 2 Andrej Nemec 2016-02-17 04:03 EST
Created attachment 1127890 [details]
second VMS patch
Comment 6 Cedric Buissart 2016-03-02 04:14:12 EST
Created perl tracking bugs for this issue:

Affects: fedora-all [bug 1313702]
Comment 7 Fedora Update System 2016-03-03 15:22:08 EST
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.
Comment 8 Cedric Buissart 2016-03-10 09:55:39 EST
Acknowledgments:

Name: Stephane Chazelas
Comment 10 Fedora Update System 2016-03-13 05:51:31 EDT
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.
Comment 11 Trevor Cordes 2016-03-14 01:18:34 EDT
Resolution: --- → WONTFIX
???
-> errata?
Comment 12 Cedric Buissart 2016-03-15 07:35:36 EDT
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
fix.

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 secalert@redhat.com

Note You need to log in before you can comment on or make changes to this bug.