Bug 173793 - CAN-2005-0448 perl File::Path.pm rmtree race condition
Summary: CAN-2005-0448 perl File::Path.pm rmtree race condition
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: 4
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: David Lawrence
URL:
Whiteboard: impact=low,public=20050309,source=cve...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-21 08:54 UTC by Mark J. Cox
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-21 23:18:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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