On Nov 19, 2008, at 16:43 , Nicholas Clark wrote:
> On Wed, Nov 19, 2008 at 04:25:58PM +0100, Gisle Aas wrote:
>> On Nov 19, 2008, at 11:59 , Nicholas Clark wrote:
>>
>>> On Fri, Nov 14, 2008 at 11:59:22AM +0100, Gisle Aas wrote:
>>>> On Nov 14, 2008, at 11:15 , Nicholas Clark wrote:
>>>>> True. I considered this, but then we get back to a version with a
>>>>> CVE,
>>>>> don't we?
>>>>
>>>> No. perl-5.8.8 shipped with File-Path-1.08 and the CVE-2008-2827
>>>> was
>>>> introduced in the 2.xx series.
>>>
>>> I believe we're back to code with CVE-2002-0435
>>
>> No. File::Path has never had the problem described in CVE-2002-0435.
>> It's a bit confusing that the current File::Path documentation
>> reference this CVE; but it's mainly to point out that the implementor
>> thought about this issue when implementing the new chdir based
>> approach to rmtree.
>>
>> But, File::Path 1.08 does have the problem described in
>> CVE-2005-0448. Several vendors (including us at ActiveState) patched
>> this, but the patch was not portable to VMS so it could not go into
>> core perl.
>>
>> And to complete the CVE history of File::Path; v1.07 fixed
>> CVE-2004-0452 and was distributed first in perl-5.8.7.
>>
>> Reviewing all these CVEs today I found that File::Path 2.07 still
>> suffers from CVE-2005-0448. I'm sure you're delighted to learn
>> that :)
>
> Thanks for that correction and clarification.
>
> So, I have it right that the security summary is that:
>
> 5.8.8 ships with File::Path 1.08, which is vulnerable to only
> CVE-2005-0448
> File::Path 2.07 is vulnerable to only CVE-2005-0448
That's right, but it's just a trivial patch to fix the issue in
File::Path 2.07. In File::Path 1.08 there is no easy fix.
It also means that 5.10.0 suffer from both CVE-2005-0448 and
CVE-2008-2827.
Reading the CVE descriptions and following the links there seem to be
much confusion about which issue is CVE-2005-0448 and which is
CVE-2005-0452. Change 23953 claims to fix CVE-2005-0452, but I
actually think it fixed CVE-2005-0448 and that CVE-2005-0452 is the
one we actually still have outstanding. It's really confusing.
Anyway, the attack that's still possible with 2.07 is the one
described by Paul Szabo in <
http://bugs.debian.org/286905>. I belive
the following patch (on top of 2.07) fixes it:
diff --git a/Path.pm b/Path.pm
index 128d95b..f38d242 100644
--- a/Path.pm
+++ b/Path.pm
@@ -333,7 +333,7 @@ sub _rmtree {
}
else {
_error($arg, "cannot remove directory", $canon);
- if (!chmod($perm, ($Is_VMS ?
VMS::Filespec::fileify($root) : $root))
+ if ($Force_Writeable && !chmod($perm, ($Is_VMS ?
VMS::Filespec::fileify($root) : $root))
) {
_error($arg, sprintf("cannot restore
permissions to 0%o",$perm), $canon);
}
David, can you tell us what you want to happen? Can you wrap up 2.08
now?
--Gisle
>>> I would be most happy if File::Path 2.08 removed the check code, and
>>> 2.09 re-added it, patched and fixed, and 5.8.9 shipped with 2.08
>
>> Seems like a good plan to me. But now it looks like 2.08 also ought
>> to resolve CVE-2005-0448. I'll work out a patch.
>
> OK. But my concern is
>
> 5.8.9-RC2 is waiting on this
> 5.8.9 release is waiting on 5.8.9-RC2
> git migration is waiting on 5.8.9 release
> realistically, integration work for 5.10.1 waits on git migration
> Christmas is waiting on 5.10.1. (Or at least Hogmanay)
>
>
> And I'd really really like to ship the thing and get on with the
> rest of my
> life.
>
>
> And right now, *if* File::Path 1.08 is equally vulnerable as
> File::Path 2.07
> plus just-a-fix for the temporary directory deletion problem, then
> the best
> way to minimise the risk of 5.8.9-RC3 is to go back to File::Path 1.08
>
> Nicholas Clark