Bug 847949

Summary:	CVE-2012-3878 perl: "require" directive allows to load files from paths not stored in @INC
Product:	Red Hat Enterprise Linux 7	Reporter:	Stefan Cornelius <scorneli>
Component:	perl	Assignee:	perl-maint-list
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	low	Docs Contact:
Priority:	low
Version:	7.0	CC:	carnil, ppisar
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Unspecified
URL:	http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189909.html
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-03 10:26:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Stefan Cornelius 2012-08-14 07:32:44 UTC

It was discovered that the "require" directive allows to load files from paths not stored in @INC. If a Perl application allows users to specify arbitrary module names and an attacker can place a malicious file containing Perl code ending with .pm or .pmc on the local file system, he could exploit this behaviour to load and execute the malicious file.

http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189909.html
http://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/require

Comment 1 Stefan Cornelius 2012-08-14 07:33:31 UTC

*** Bug 840895 has been marked as a duplicate of this bug. ***

Comment 2 Marcela Mašláňová 2012-08-14 13:22:02 UTC

The new behaviour of require will be default in perl-5.16.x. It might be in perldelta, but it's not there yet. We might document it.

Comment 4 Petr Pisar 2013-10-30 12:10:00 UTC

Upstream has never merged the change into blead and never released a perl version which would incorporate the change:

v5.18.1:
$ strace perl -e 'require ::tmp::foo' 2>&1 | grep foo
execve("/bin/perl", ["perl", "-e", "require ::tmp::foo"], [/* 20 vars */]) = 0
stat("/tmp/foo.pmc", 0x7fff5ec8e3d0)    = -1 ENOENT (No such file or directory)
stat("/tmp/foo.pm", 0x7fff5ec8e310)     = -1 ENOENT (No such file or directory)
write(2, "Can't locate /tmp/foo.pm in @INC"..., 252Can't locate /tmp/foo.pm in @INC (you may need to install the ::tmp::foo module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at -e line 1.

v5.16.3:
# strace perl -e 'require ::tmp::foo' 2>&1 | grep foo
execve("/usr/bin/perl", ["perl", "-e", "require ::tmp::foo"], [/* 30 vars */]) = 0
stat("/tmp/foo.pmc", 0x7fff5749fbb0)    = -1 ENOENT (No such file or directory)
stat("/tmp/foo.pm", 0x7fff5749fb00)     = -1 ENOENT (No such file or directory)
write(2, "Can't locate /tmp/foo.pm in @INC"..., 204Can't locate /tmp/foo.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at -e line 1.

As you can see, the leading quad-dot still resolves to absolute path.

In my opinion, upstream put the resolution into dormant state.

Because the fix changes behavior, I cannot consider applying it into our distribution as a good resolution.

Comment 5 Petr Pisar 2014-06-03 10:26:14 UTC

(In reply to Petr Pisar from comment #4)
> Because the fix changes behavior, I cannot consider applying it into our
> distribution as a good resolution.

If you want to see this change in a future major Red Hat Enterprise Linux release, please persuade upstream to accept this change first.