Bug 173793

Summary:	CAN-2005-0448 perl File::Path.pm rmtree race condition
Product:	[Fedora] Fedora	Reporter:	Mark J. Cox <mjc>
Component:	perl	Assignee:	Jason Vas Dias <jvdias>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4	CC:	perl-devel, wtogami
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	impact=low,public=20050309,source=cve,reported=20050314
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-11-21 23:18:29 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:

Description Mark J. Cox 2005-11-21 08:54:14 UTC

+++ This bug was initially created as a clone of Bug #157695 +++

Race condition in the rmtree function in File::Path.pm in Perl before 5.8.4
allows local users to create arbitrary setuid binaries in the tree being
deleted, a different vulnerability than CAN-2004-0452.

http://marc.theaimsgroup.com/?l=bugtraq&m=111039131424834&w=2

attachment 114350 [details] contains the ubuntu patch (it needs some cleaning up)

-- Additional comment from wtogami on 2005-05-28 02:05 EST --
"Race condition in the rmtree function in File::Path.pm in Perl before 5.8.4
allows local users to create arbitrary setuid binaries"

5.8.4 means FC3 is unaffected because we have perl-5.8.5?  Can someone confirm?

-- Additional comment from bressers on 2005-05-28 08:41 EST --
Warren,

I just took a look at the latest perl source, this issue has not been fixed by
upstream.  It's proving very hard to do right, which is probably why upstream
hasn't done it yet.

-- Additional comment from wtogami on 2005-05-31 06:40 EST --
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=114350
Attachment to fix this security bug is from Ubuntu, but we require help cleaning
it up and testing before issuing a FC3 update.  Apparently this is a difficult
problem to fix, and this is our second attempt doing so. =(


-- Additional comment from prockai on 2005-06-15 14:01 EST --
Created an attachment (id=115494)
debian's 03_fix_file_path

Why not just use the debian patch? (attached)

-- Additional comment from prockai on 2005-06-16 04:22 EST --
Assigning to self. 

-- Additional comment from prockai on 2005-06-16 08:15 EST --
Patched in CVS. Testing requested - if anyone has an exploit or something like 
that, please try out. The testsuite passes exactly like before patching, but 
regression testing is welcome as well. 

-- Additional comment from prockai on 2005-07-28 09:07 EST --
Fixed in FC3 update perl-5.8.5-14.FC3

Comment 1 Jason Vas Dias 2005-11-21 23:18:29 UTC

perl 5.8.6 in FC-4 and perl-5.8.7 in FC-5 should NOT be vulnerable to this 
exploit - if anyone has found to the contrary, please supply a test case
(perl script that exploits the vulnerability). 

I think the CVE is correct in stating that this is only a problem with 5.8.3(-).

The 5.8.7 rmtree differs from that of 5.8.6 ONLY in potentially adding more
privileges when it does the chmod before the remove - it sets the permissions
of each file to ($rp | 0x00), where $rp is the permissions of the path being
removed, instead of FC-4's 0x00, and in adding better support for VMS .

Debian has gone with its own implementation of Path::rmtree, which is 
incompatible with the upstream version and shows no sign of being accepted
there, and still carries the same warnings about the fundamental insecurity
of the whole algorithm used by Path::rmtree . 

Gentoo basically copies Debian's patch.

Neither Trustix nor OWL patch the upstream 5.8.7/5.8.6 Path::rmtree code at all.

I think we should minimise the differences between our perl distribution and
the upstream version. Since neither trustix nor owl have seen fit to patch
the 5.8.6 or 5.8.7 Path::rmtree, and since no exploits for the 5.8.6/5.8.7
rmtree have been reported, I think we should stick with the upstream version.