Bug 173793 - CAN-2005-0448 perl File::Path.pm rmtree race condition
CAN-2005-0448 perl File::Path.pm rmtree race condition
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
4
All Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
David Lawrence
impact=low,public=20050309,source=cve...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-21 03:54 EST by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-21 18:18:29 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)

  None (edit)
Description Mark J. Cox (Product Security) 2005-11-21 03:54:14 EST
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2005-06-16 04:22 EST --
Assigning to self. 

-- Additional comment from prockai@redhat.com 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@redhat.com 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 18:18:29 EST
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.