Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 79685 - dev-lang/perl: File::Path::rmtree still vulnerable to a race condition
Summary: dev-lang/perl: File::Path::rmtree still vulnerable to a race condition
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High minor (vote)
Assignee: Gentoo Security
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard: B3 [glsa] koon
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-27 02:10 UTC by Thierry Carrez (RETIRED)
Modified: 2005-03-15 07:39 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
rmtree.patch (rmtree.patch,7.49 KB, patch)
2005-03-08 05:56 UTC, Thierry Carrez (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thierry Carrez (RETIRED) gentoo-dev 2005-01-27 02:10:25 UTC
Paul Szabo brought to our attention that the fix for CAN-2004-0452 does not handle all race conditions case and that rmtree is still vulnerable :

=============================================
Just changing the chmod to 0700 and 0600 instead of 0777 and 0666
does NOT solve the issue. The chmod change was for another, but related,
problem. See bugs.debian.org/286905 and 286922.
=============================================
Comment 1 Thierry Carrez (RETIRED) gentoo-dev 2005-01-27 02:11:38 UTC
Looking for a definitive patch for this issue.
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-02-07 09:16:36 UTC
Comments about rmtree committed into Owl release :

==========================
There're race conditions internal to the implementation of <rmtree> making it unsafe to use on directory trees which may be altered or moved while <rmtree> is running, and in particular on any directory trees with any path components or subdirectories potentially writable by untrusted users.

Additionally, if the third parameter is not TRUE and <rmtree> is interrupted, it may leave files and directories with permissions altered to allow deletion (and older versions of this module would even set files and directories to world-read/writable!)

Note also that the occurrence of errors in <rmtree> can be determined only by trapping diagnostic messages using $SIG{__WARN__}; it is not apparent from the return value.
=========================

Maybe we should "fix" this by documenting it like this.
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-03-02 06:51:21 UTC
I think we should close this one. rmtree has race conditions by design... Comments ?
Comment 4 Thierry Carrez (RETIRED) gentoo-dev 2005-03-08 05:56:25 UTC
Created attachment 52935 [details, diff]
rmtree.patch

Patch from Debian (applies cleanly if you don't apply the previous
file_path_rmtree.patch)

Warning! This patch seems to ignore macos specific code:

"I've also ignored $Is_VMS and $Is_MacOS; will need some input from
perl5-porters as to what changes are required to support those
platforms."

CAN-2005-0448
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2005-03-08 05:57:43 UTC
Perl team, please apply patch or comment...
Comment 6 Michael Cummings (RETIRED) gentoo-dev 2005-03-08 07:04:15 UTC
Are we worried about macos support (which is lacking in this patch) (and i see them lurking over my shoulder)?

I still want to say that this patch doesn't defeat the race condition, but comes pretty close (relies on the inode/stat of the dir comparing before and after a chdir). Would this still work on an nfs mount where the nfs sync wasn't running up to par, ie, changes made on another server with the nfs mount don't get replicated across until after the chdir occurs? just saying...

for general purpose uses, yes, this patch should cover most cases, and I may be overthinking/misunderstanding it :)
Comment 7 Thierry Carrez (RETIRED) gentoo-dev 2005-03-08 07:19:21 UTC
I think we can commit this and forget to add macos keywords, and let them patch the patch if needed when they add their own keywords ? Or we can pull them in so that they do it now.

Adding ppc-macos herd to the mix.
Comment 8 Lina Pezzella (RETIRED) gentoo-dev 2005-03-08 10:32:40 UTC
Go ahead and push it through. ppc-macos will not be keywording anything perl in the near future.
Comment 9 Michael Cummings (RETIRED) gentoo-dev 2005-03-09 11:16:12 UTC
Confirmed that it applies and runs smoothly on all three versions in the tree. Are we good for a version bump & release or do you need time?
Comment 10 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-03-10 11:03:09 UTC
Micheal please go ahead.
Comment 11 Michael Cummings (RETIRED) gentoo-dev 2005-03-11 07:13:55 UTC
Posted and bumped across the board.
Comment 12 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-03-11 07:19:00 UTC
Thx Micheal. This one is ready for GLSA vote.
Comment 13 Michael Cummings (RETIRED) gentoo-dev 2005-03-11 11:14:26 UTC
STOP. I messed up somewhere and need to roll back and get this fixed. I read the patch, read it as clean, but as soon as it hit the tree I started getting bug reports against it. I accept responsibility for this,

Mike
Comment 14 Michael Cummings (RETIRED) gentoo-dev 2005-03-11 12:19:46 UTC
I'm rolling back until we can get a better solution. This patch will break this module on any box that changes kernel versions. I don't deny that a fix is needed, but the problem is that in using Errno, it uses /usr/lib*/perl5/<current-version>/<archversion>/Errno.pm (path varies depending on arch), which records your kernel version/platform at install. This patch invokes it and throws an error for anyone that has changed kernels.
Comment 15 Luke Macken (RETIRED) gentoo-dev 2005-03-11 12:48:55 UTC
back to [ebuild] status.
Comment 16 Michael Cummings (RETIRED) gentoo-dev 2005-03-11 13:45:03 UTC
I don't know if I've ever had such a frantic session...fixed. For good. Patching from a better location in the process.
Comment 17 Luke Macken (RETIRED) gentoo-dev 2005-03-11 21:38:25 UTC
Nice save Michael :)

Security, please vote on GLSA.
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2005-03-14 01:21:20 UTC
I vote yes, as an update to GLSA 200501-38
Comment 19 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-03-15 02:01:35 UTC
I vote YES to the GLSA update as well.
Comment 20 Thierry Carrez (RETIRED) gentoo-dev 2005-03-15 04:44:12 UTC
I'll do it
Comment 21 Thierry Carrez (RETIRED) gentoo-dev 2005-03-15 07:39:33 UTC
Released as GLSA 200501-38:03 update