Bug 1309214 (CVE-2016-2381)

Summary: CVE-2016-2381 perl: ambiguous environment variables handling
Product: [Other] Security Response Reporter: Andrej Nemec <anemec>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: carnil, cbuissar, hhorak, jorton, jplesnik, mmaslano, perl-maint-list, ppisar, psabata, rh, rmeggins, security-response-team, slawomir, trevor
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-09 15:28:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1313702    
Bug Blocks: 1309216    
Attachments:
Description Flags
first patch
none
second VMS patch none

Description Andrej Nemec 2016-02-17 09:01:59 UTC 
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 09:03:00 UTC 
Created attachment 1127889 [details]
first patch
Comment 2 Andrej Nemec 2016-02-17 09:03:32 UTC 
Created attachment 1127890 [details]
second VMS patch
Comment 6 Cedric Buissart 2016-03-02 09:14:12 UTC 
Created perl tracking bugs for this issue:

Affects: fedora-all [bug 1313702]
Comment 7 Fedora Update System 2016-03-03 20:22:08 UTC 
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 14:55:39 UTC 
Acknowledgments:

Name: Stephane Chazelas
Comment 10 Fedora Update System 2016-03-13 09:51:31 UTC 
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 05:18:34 UTC 
Resolution: --- → WONTFIX
???
-> errata?
Comment 12 Cedric Buissart 2016-03-15 11:35:36 UTC 
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