perl-modules: File::Path::rmtree makes setuid
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
perl (Debian) |
Fix Released
|
Unknown
|
|||
perl (Ubuntu) |
Fix Released
|
High
|
Martin Pitt |
Bug Description
Automatically imported from Debian bug report #286905 http://
Debian Bug Importer (debzilla) wrote : | #1 |
Debian Bug Importer (debzilla) wrote : | #2 |
Message-Id: <email address hidden>
Date: Thu, 23 Dec 2004 09:10:31 +1100
From: Paul Szabo <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: perl-modules: File::Path::rmtree makes setuid
Package: perl-modules
Version: 5.6.1-8.7
Severity: critical
File: /usr/share/
Tags: security
Justification: root security hole
Noting USN-44-1 e.g. in
http://
I looked in perl-N.
a race condition, allowing creation of setuid files:
170 (undef, undef, my $rp) = lstat $root or next;
171 $rp &= 07777; # don't forget setuid, setgid, sticky bits
172 if ( -d _ ) {
...
209 if (rmdir $root) {
210 ++$count;
211 }
212 else {
213 carp "Can't remove directory $root: $!";
214 chmod($rp, ($Is_VMS ? VMS::Filespec:
215 or carp("and can't restore permissions to "
216 . sprintf("0%o",$rp) . "\n");
217 }
218 }
...
Example of attack: suppose we know that root uses rmtree to clean up
/tmp directories. Attacker prepares things:
mkdir -p /tmp/psz/sh
perl -e 'open F, ">/tmp/psz/sh/$_" foreach (1..1000)'
chmod 4777 /tmp/psz/sh
While root is busy working on /tmp/psz/sh (and this can be made as slow
as we like), attacker does:
mv /tmp/psz/sh /tmp/psz/dummy
ln -s /bin/sh /tmp/psz/sh
Root would have recorded the permissions of /tmp/psz/sh, but would
"restore" it to /bin/sh.
I am not sure if things can almost be fixed (for those architectures
without $force_writeable) by enclosing the chmod($rp,...) line within
if(!safe|
rmtree must only be used if you can be sure to have exclusive access to
the tree.
(A few minutes ago I emailed the File::Path authors <email address hidden>
and <email address hidden>; Tim.Bunce bounced.)
Cheers,
Paul Szabo - <email address hidden> http://
School of Mathematics and Statistics University of Sydney 2006 Australia
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux pisa.maths.
Locale: LANG=C, LC_CTYPE=C
Versions of packages perl-modules depends on:
ii perl 5.6.1-8.7 Larry Wall's Practical Extraction
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : bug twiddling | #3 |
# reassign to canonical package
reassign 255093 perl
reassign 255919 perl
reassign 257568 perl
reassign 262957 perl
reassign 263279 perl
reassign 263325 perl
reassign 264629 perl
reassign 266194 perl
reassign 266669 perl
reassign 268810 perl
reassign 269879 perl
reassign 269919 perl
reassign 273379 perl
reassign 275142 perl
reassign 278322 perl
reassign 280220 perl
reassign 282110 perl
reassign 283802 perl
reassign 284489 perl
reassign 286905 perl
reassign 286907 perl
reassign 286922 perl
# related security issues with File::Path::rmtree
merge 286905 286922
thanks
Debian Bug Importer (debzilla) wrote : | #4 |
Message-ID: <email address hidden>
Date: Fri, 24 Dec 2004 10:30:44 +1100
From: Brendan O'Dea <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: bug twiddling
# reassign to canonical package
reassign 255093 perl
reassign 255919 perl
reassign 257568 perl
reassign 262957 perl
reassign 263279 perl
reassign 263325 perl
reassign 264629 perl
reassign 266194 perl
reassign 266669 perl
reassign 268810 perl
reassign 269879 perl
reassign 269919 perl
reassign 273379 perl
reassign 275142 perl
reassign 278322 perl
reassign 280220 perl
reassign 282110 perl
reassign 283802 perl
reassign 284489 perl
reassign 286905 perl
reassign 286907 perl
reassign 286922 perl
# related security issues with File::Path::rmtree
merge 286905 286922
thanks
Debian Bug Importer (debzilla) wrote : | #5 |
*** Bug 11409 has been marked as a duplicate of this bug. ***
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : Re: Bug#286905: perl-modules: File::Path::rmtree makes setuid | #6 |
On Thu, Dec 23, 2004 at 09:10:31AM +1100, Paul Szabo wrote:
>Package: perl-modules
>Version: 5.6.1-8.7
>Severity: critical
>File: /usr/share/
>Tags: security
>Justification: root security hole
>Example of attack: suppose we know that root uses rmtree to clean up
>/tmp directories. Attacker prepares things:
>
> mkdir -p /tmp/psz/sh
> perl -e 'open F, ">/tmp/psz/sh/$_" foreach (1..1000)'
> chmod 4777 /tmp/psz/sh
>
>While root is busy working on /tmp/psz/sh (and this can be made as slow
>as we like), attacker does:
>
> mv /tmp/psz/sh /tmp/psz/dummy
> ln -s /bin/sh /tmp/psz/sh
>
>Root would have recorded the permissions of /tmp/psz/sh, but would
>"restore" it to /bin/sh.
>Following on from the "File::Path::rmtree makes setuid" issue, I notice
>that rmtree may be tricked into removing arbitrary files.
>
>Example of attack: suppose we know that root uses rmtree to clean up
>/tmp directories. Attacker prepares things:
>
> mkdir /tmp/psz
> perl -e 'open F, ">/tmp/psz/$_" foreach (1..1000)'
> touch /tmp/psz/passwd
>
>While root is busy working on /tmp/psz (and this can be made as slow as
>we like), attacker does:
>
> mv /tmp/psz /tmp/dummy
> ln -s /etc /tmp/psz
>
>Root will then remove /etc/passwd.
Thanks Paul,
both of these issues obviously stem from the same root cause--a race
between generating a list of files, then manipulating that list.
I don't really see that this is fixable outside of rewriting rmtree to
recursively chdir+readdir+
Given that there are possible pitfalls even with this approach (cf.
CVE-2002-0435) I'm considering punting the problem to fileutils,
replacing rmtree entirely with the attached subroutine.
[p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
hear of it.
--bod
sub rmtree
{
my ($p, $verbose) = @_;
$p = [] unless defined $p and length $p;
$p = [ $p ] unless ref $p;
my @paths = grep defined && length, @$p;
unless (@paths)
{
carp "No root path(s) specified\n";
return 0;
}
local *RM;
my $pid = open RM, '-|';
unless (defined $pid)
{
carp "Can't fork ($!)\n";
return 0;
}
unless ($pid)
{
# need to parse output, ensure it's not localised
delete $ENV{$_} for grep /^(LC_|
exec '/bin/rm', '-rvf', @paths
or croak "Can't exec /bin/rm ($!)\n";
}
my $count = 0;
while (<RM>)
{
if ($verbose)
{
chomp;
s/'$//;
if (s/^removed directory: `//)
{
print "rmdir $_\n";
}
elsif (s/^removed `//)
{
print "unlink $_\n";
}
$count++;
}
}
close RM;
$count;
}
In Debian Bug tracker #286905, Rafael Garcia-Suarez (rgarciasuarez) wrote : | #7 |
How does this relate to the Debian patch 22_fix_file_path
for CAN-2004-0452 ? which I'm pasting below.
That said, an implementation of rmtree() that uses /bin/rm
isn't suitable for inclusion in perl itself.
http://
[Adapted from Chip Turner's 5.8.0 patch]
Fix for CAN-2004-0452. Change chmod's to make files writable/executable
by the current user only and not by the entire world. chmod's necessary
in the first place but at least this makes them less dangerous. If, for
some reason the rm process dies halfway through, at worst some files and
dirs were revoked from others, not made available.
--- lib/File/Path.pm 2001-03-21 04:40:22.000000000 +1100
+++ lib/File/Path.pm 2004-12-22 23:46:54.000000000 +1100
@@ -174,7 +174,7 @@
# it's also intended to change it to writable in case we have
# to recurse in which case we are better than rm -rf for
# subtrees with strange permissions
- chmod(0777, ($Is_VMS ? VMS::Filespec:
+ chmod(0700, ($Is_VMS ? VMS::Filespec:
or carp "Can't make directory $root read+writeable: $!"
@@ -202,7 +202,7 @@
}
- chmod 0777, $root
+ chmod 0700, $root
or carp "Can't make directory $root writeable: $!"
if $force_writeable;
print "rmdir $root\n" if $verbose;
@@ -224,7 +224,7 @@
}
- chmod 0666, $root
+ chmod 0600, $root
or carp "Can't make file $root writeable: $!"
if $force_writeable;
print "unlink $root\n" if $verbose;
Debian Bug Importer (debzilla) wrote : | #8 |
Message-ID: <email address hidden>
Date: Wed, 12 Jan 2005 23:45:57 +1100
From: Brendan O'Dea <email address hidden>
To: Paul Szabo <email address hidden>, <email address hidden>
Cc: Perl5 Porters <email address hidden>
Subject: Re: Bug#286905: perl-modules: File::Path::rmtree makes setuid
On Thu, Dec 23, 2004 at 09:10:31AM +1100, Paul Szabo wrote:
>Package: perl-modules
>Version: 5.6.1-8.7
>Severity: critical
>File: /usr/share/
>Tags: security
>Justification: root security hole
>Example of attack: suppose we know that root uses rmtree to clean up
>/tmp directories. Attacker prepares things:
>
> mkdir -p /tmp/psz/sh
> perl -e 'open F, ">/tmp/psz/sh/$_" foreach (1..1000)'
> chmod 4777 /tmp/psz/sh
>
>While root is busy working on /tmp/psz/sh (and this can be made as slow
>as we like), attacker does:
>
> mv /tmp/psz/sh /tmp/psz/dummy
> ln -s /bin/sh /tmp/psz/sh
>
>Root would have recorded the permissions of /tmp/psz/sh, but would
>"restore" it to /bin/sh.
>Following on from the "File::Path::rmtree makes setuid" issue, I notice
>that rmtree may be tricked into removing arbitrary files.
>
>Example of attack: suppose we know that root uses rmtree to clean up
>/tmp directories. Attacker prepares things:
>
> mkdir /tmp/psz
> perl -e 'open F, ">/tmp/psz/$_" foreach (1..1000)'
> touch /tmp/psz/passwd
>
>While root is busy working on /tmp/psz (and this can be made as slow as
>we like), attacker does:
>
> mv /tmp/psz /tmp/dummy
> ln -s /etc /tmp/psz
>
>Root will then remove /etc/passwd.
Thanks Paul,
both of these issues obviously stem from the same root cause--a race
between generating a list of files, then manipulating that list.
I don't really see that this is fixable outside of rewriting rmtree to
recursively chdir+readdir+
Given that there are possible pitfalls even with this approach (cf.
CVE-2002-0435) I'm considering punting the problem to fileutils,
replacing rmtree entirely with the attached subroutine.
[p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
hear of it.
--bod
sub rmtree
{
my ($p, $verbose) = @_;
$p = [] unless defined $p and length $p;
$p = [ $p ] unless ref $p;
my @paths = grep defined && length, @$p;
unless (@paths)
{
carp "No root path(s) specified\n";
return 0;
}
local *RM;
my $pid = open RM, '-|';
unless (defined $pid)
{
carp "Can't fork ($!)\n";
return 0;
}
unless ($pid)
{
# need to parse output, ensure it's not localised
delete $ENV{$_} for grep /^(LC_|
exec '/bin/rm', '-rvf', @paths
or croak "Can't exec /bin/rm ($!)\n";
}
my $count = 0;
while (<RM>)
{
if ($verbose)
{
chomp;
s/'$//;
if (s/^removed directory: `//)
{
print "rmdir $_\n";
}
elsif (s/^removed `//)
{
print "unlink $_\n";
}
$count++;
}
}
close RM;
$count;
}
Debian Bug Importer (debzilla) wrote : | #9 |
Message-ID: <email address hidden>
Date: Wed, 12 Jan 2005 14:15:18 +0100
From: Rafael Garcia-Suarez <email address hidden>
To: Brendan O'Dea <email address hidden>
Cc: Paul Szabo <email address hidden>, <email address hidden>,
Perl5 Porters <email address hidden>
Subject: Re: Bug#286905: perl-modules: File::Path::rmtree makes setuid
How does this relate to the Debian patch 22_fix_file_path
for CAN-2004-0452 ? which I'm pasting below.
That said, an implementation of rmtree() that uses /bin/rm
isn't suitable for inclusion in perl itself.
http://
[Adapted from Chip Turner's 5.8.0 patch]
Fix for CAN-2004-0452. Change chmod's to make files writable/executable
by the current user only and not by the entire world. chmod's necessary
in the first place but at least this makes them less dangerous. If, for
some reason the rm process dies halfway through, at worst some files and
dirs were revoked from others, not made available.
--- lib/File/Path.pm 2001-03-21 04:40:22.000000000 +1100
+++ lib/File/Path.pm 2004-12-22 23:46:54.000000000 +1100
@@ -174,7 +174,7 @@
# it's also intended to change it to writable in case we have
# to recurse in which case we are better than rm -rf for
# subtrees with strange permissions
- chmod(0777, ($Is_VMS ? VMS::Filespec:
+ chmod(0700, ($Is_VMS ? VMS::Filespec:
or carp "Can't make directory $root read+writeable: $!"
@@ -202,7 +202,7 @@
}
- chmod 0777, $root
+ chmod 0700, $root
or carp "Can't make directory $root writeable: $!"
if $force_writeable;
print "rmdir $root\n" if $verbose;
@@ -224,7 +224,7 @@
}
- chmod 0666, $root
+ chmod 0600, $root
or carp "Can't make file $root writeable: $!"
if $force_writeable;
print "unlink $root\n" if $verbose;
In Debian Bug tracker #286905, Paul Szabo (psz-maths) wrote : | #10 |
Brendan O'Dea <email address hidden> wrote:
> both of these issues obviously stem from the same root cause--a race
> between generating a list of files, then manipulating that list.
The first issue "also" relies on Path.pm trying to be clever:
# notabene: 0777 is for making readable in the first place,
# it's also intended to change it to writable in case we have
# to recurse in which case we are better than rm -rf for
# subtrees with strange permissions
> I don't really see that this is fixable outside of rewriting rmtree to
> recursively chdir+readdir+
> Given that there are possible pitfalls even with this approach (cf.
> CVE-2002-0435) ...
That pitfall is known and easily avoided by double-checking inodes.
> ... I'm considering punting the problem to fileutils,
> replacing rmtree entirely with the attached subroutine.
> [p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
> hear of it.
I am not sure that all platforms have fileutils: no -v option on rm.
(Tru64 doesn't.)
Rafael Garcia-Suarez <email address hidden> wrote:
> How does this relate to the Debian patch 22_fix_file_path
> for CAN-2004-0452 ? ...
CAN-2004-0452 exploited the "chmod 0777", the fix changed the mode
to 0700 (and 0666 to 0600) but did not avoid the race.
Cheers,
Paul Szabo - <email address hidden> http://
School of Mathematics and Statistics University of Sydney 2006 Australia
Debian Bug Importer (debzilla) wrote : | #11 |
Message-Id: <email address hidden>
Date: Thu, 13 Jan 2005 05:23:46 +1100
From: <email address hidden> (<email address hidden>)
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#286905: perl-modules: File::Path::rmtree makes setuid
Brendan O'Dea <email address hidden> wrote:
> both of these issues obviously stem from the same root cause--a race
> between generating a list of files, then manipulating that list.
The first issue "also" relies on Path.pm trying to be clever:
# notabene: 0777 is for making readable in the first place,
# it's also intended to change it to writable in case we have
# to recurse in which case we are better than rm -rf for
# subtrees with strange permissions
> I don't really see that this is fixable outside of rewriting rmtree to
> recursively chdir+readdir+
> Given that there are possible pitfalls even with this approach (cf.
> CVE-2002-0435) ...
That pitfall is known and easily avoided by double-checking inodes.
> ... I'm considering punting the problem to fileutils,
> replacing rmtree entirely with the attached subroutine.
> [p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
> hear of it.
I am not sure that all platforms have fileutils: no -v option on rm.
(Tru64 doesn't.)
Rafael Garcia-Suarez <email address hidden> wrote:
> How does this relate to the Debian patch 22_fix_file_path
> for CAN-2004-0452 ? ...
CAN-2004-0452 exploited the "chmod 0777", the fix changed the mode
to 0700 (and 0666 to 0600) but did not avoid the race.
Cheers,
Paul Szabo - <email address hidden> http://
School of Mathematics and Statistics University of Sydney 2006 Australia
In Debian Bug tracker #286905, AaronSherman (ajs-ajs) wrote : | #12 |
On Wed, 2005-01-12 at 07:45, Brendan O'Dea wrote:
> >Example of attack: suppose we know that root uses rmtree to clean up
> >/tmp directories.
[...]
> >Root would have recorded the permissions of /tmp/psz/sh, but would
> >"restore" it to /bin/sh.
I'll discuss this one, below with my reply to Brendan.
As a general response: the solution to this and any number of other
vulnerabilities is a system that presents filesystem multi-stage
transactions. That's not something Perl can rely on, but it's certainly
something Perl should support when it does exist (perhaps Reiser has
already gone there?)
Ok, now back to reality:
> >Following on from the "File::Path::rmtree makes setuid" issue, I notice
> >that rmtree may be tricked into removing arbitrary files.
> >
> >Example of attack: suppose we know that root uses rmtree to clean up
> >/tmp directories. Attacker prepares things:
You cited a general solution, and it's a good one. You have to chdir
into the directory and then readdir, restoring state as you go back up.
You also need to sanity check using Cwd and File::Spec before and after
the chdir to make sure that you didn't get hijacked.
> [p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
> hear of it.
Well, certainly relying on rm (and you assumed a "-v" option which,
AFAIK implies GNU rm specifically) is right out. I'm sure others will
say the same.
Also, I don't see the value in changing permissions.
I understand WHY you want to do this, but it's far better to tell the
programmer calling rmtree that they might have to fix permissions before
calling rmtree. Otherwise, rmtree is doing exactly what your permissions
told it to, and you might have done that for a reason. Is it any worse
to have a developer say, "I made that directory read-only to all, but
rmtree nuked it!" vs. "I made that directory read-only to all, and
rmtree didn't nuke it!"? I can make that argument either way with just
as much sincerity and "oh my gods, you can't do this to me!" pleading as
I'm sure you've heard on this in the past... solution: punt.
Quick fix? Reduce the race by making any changes just before and just
after an operation, not in preparation for a whole directory. Now you
still have a problem, but a smaller one.
Further reduce the problem by using device/inode information from stat
on platforms where it is available. You can't make this atomic, but when
you need to do:
if (! do_something()) {
revert_change();
}
checking just before revert_change() will reduce the race substantially.
Also, consider writing sanity-checking wrappers that handle all of this,
so that future additions don't have to boiler-plate your security code.
--
☎ 781-324-3772
✉ <email address hidden>
☷ http://
Debian Bug Importer (debzilla) wrote : | #13 |
Message-Id: <1105567361.
Date: Wed, 12 Jan 2005 17:02:41 -0500
From: Aaron Sherman <email address hidden>
To: "Brendan O'Dea" <email address hidden>
Cc: <email address hidden>, Perl5 Porters List <email address hidden>
Subject: Re: Bug#286905: perl-modules: File::Path::rmtree makes setuid
On Wed, 2005-01-12 at 07:45, Brendan O'Dea wrote:
> >Example of attack: suppose we know that root uses rmtree to clean up
> >/tmp directories.
[...]
> >Root would have recorded the permissions of /tmp/psz/sh, but would
> >"restore" it to /bin/sh.
I'll discuss this one, below with my reply to Brendan.
As a general response: the solution to this and any number of other
vulnerabilities is a system that presents filesystem multi-stage
transactions. That's not something Perl can rely on, but it's certainly
something Perl should support when it does exist (perhaps Reiser has
already gone there?)
Ok, now back to reality:
> >Following on from the "File::Path::rmtree makes setuid" issue, I notic=
e
> >that rmtree may be tricked into removing arbitrary files.
> >
> >Example of attack: suppose we know that root uses rmtree to clean up
> >/tmp directories. Attacker prepares things:
You cited a general solution, and it's a good one. You have to chdir
into the directory and then readdir, restoring state as you go back up.
You also need to sanity check using Cwd and File::Spec before and after
the chdir to make sure that you didn't get hijacked.
> [p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
> hear of it.
Well, certainly relying on rm (and you assumed a "-v" option which,
AFAIK implies GNU rm specifically) is right out. I'm sure others will
say the same.
Also, I don't see the value in changing permissions.
I understand WHY you want to do this, but it's far better to tell the
programmer calling rmtree that they might have to fix permissions before
calling rmtree. Otherwise, rmtree is doing exactly what your permissions
told it to, and you might have done that for a reason. Is it any worse
to have a developer say, "I made that directory read-only to all, but
rmtree nuked it!" vs. "I made that directory read-only to all, and
rmtree didn't nuke it!"? I can make that argument either way with just
as much sincerity and "oh my gods, you can't do this to me!" pleading as
I'm sure you've heard on this in the past... solution: punt.
Quick fix? Reduce the race by making any changes just before and just
after an operation, not in preparation for a whole directory. Now you
still have a problem, but a smaller one.
Further reduce the problem by using device/inode information from stat
on platforms where it is available. You can't make this atomic, but when
you need to do:
if (! do_something()) {
revert_change();
}
checking just before revert_change() will reduce the race substantially.
Also, consider writing sanity-checking wrappers that handle all of this,
so that future additions don't have to boiler-plate your security code.
--=20
=E2=98=8E 781-324-3772
=E2=9C=89 <email address hidden>
=E2=98=B7 http://
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : | #14 |
On Wed, Jan 12, 2005 at 05:02:41PM -0500, Aaron Sherman wrote:
>> [p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
>> hear of it.
>
>Well, certainly relying on rm (and you assumed a "-v" option which,
>AFAIK implies GNU rm specifically) is right out. I'm sure others will
>say the same.
Sure, it was proposed as a quick hack for the Debian package, where it
is safe to assume /bin/rm is from GNU coreutils.
If it weren't for the requirement to retain the current API (returning
the number of deletions, and verbose output) then a thin wrapper around
system 'rm', '-rf', @paths
would suffix for POSIX systems.
>Quick fix? Reduce the race by making any changes just before and just
>after an operation, not in preparation for a whole directory. Now you
>still have a problem, but a smaller one.
A race is a race, no matter how small the window.
--bod
Debian Bug Importer (debzilla) wrote : | #15 |
Message-ID: <email address hidden>
Date: Mon, 24 Jan 2005 22:31:21 +1100
From: Brendan O'Dea <email address hidden>
To: Aaron Sherman <email address hidden>
Cc: <email address hidden>, Paul Szabo <email address hidden>,
Perl5 Porters List <email address hidden>
Subject: Re: Bug#286905: perl-modules: File::Path::rmtree makes setuid
On Wed, Jan 12, 2005 at 05:02:41PM -0500, Aaron Sherman wrote:
>> [p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to
>> hear of it.
>
>Well, certainly relying on rm (and you assumed a "-v" option which,
>AFAIK implies GNU rm specifically) is right out. I'm sure others will
>say the same.
Sure, it was proposed as a quick hack for the Debian package, where it
is safe to assume /bin/rm is from GNU coreutils.
If it weren't for the requirement to retain the current API (returning
the number of deletions, and verbose output) then a thin wrapper around
system 'rm', '-rf', @paths
would suffix for POSIX systems.
>Quick fix? Reduce the race by making any changes just before and just
>after an operation, not in preparation for a whole directory. Now you
>still have a problem, but a smaller one.
A race is a race, no matter how small the window.
--bod
In Debian Bug tracker #286905, Arne Wichmann (aw-net) wrote : | #16 |
Hi. As this Bug is now lying around for more than one month I decided to
look into a fix. It is not a very beautiful one, it is only partially
tested and it only works for systems which can fork, so please look over it
before applying it.
The idea is to fork off a process, change into the directory, make sure the
directory has the same inode which was originally used, and then change
permissions. fchmod would have been much easier.
A diff follows:
-- snip --
--- Path.pm 2005-02-08 13:23:10.000000000 +0100
+++ Path.pm.new 2005-02-08 17:13:04.000000000 +0100
@@ -189,7 +189,7 @@
} else {
$root =~ s#/\z##;
}
- (undef, undef, my $rp) = lstat $root or next;
+ (undef, my $ino, my $rp) = lstat $root or next;
$rp &= 07777; # don't forget setuid, setgid, sticky bits
if ( -d _ ) {
# notabene: 0700 is for making readable in the first place,
@@ -239,9 +239,25 @@
}
else {
- chmod($rp, ($Is_VMS ? VMS::Filespec:
+ # this avoids a race condition which would occur if someone
+ # replaced $root while we were working on it. I would have
+ # preferred to use fchmod, but this seems not to be
+ # supported in perl. -- AW
+ my($fork)=fork;
+ if ($fork<0) {carp("and cannot fork: $!");}
+ elsif ($fork>0) { # parent
+ waitpid($fork,0);
+ } else { # child
+ chdir($root) or carp("and cannot change to $root: $!");
+ (undef,
+ $rino==$ino or carp(
+ "and someone replaced $root while I was working on it\n");
+ $rino==$ino
+ and chmod($rp,($Is_VMS ? VMS::Filespec:
+ exit(0);
+ }
}
}
else {
-- snip --
I hope this helps.
cu
AW
--
<ThePhonk> *tueteKlammernU
+Miststueck!
Debian Bug Importer (debzilla) wrote : | #17 |
Message-ID: <email address hidden>
Date: Tue, 8 Feb 2005 17:14:44 +0100
From: Arne Wichmann <email address hidden>
To: <email address hidden>
Subject: perl-modules: File::Path::rmtree makes setuid
--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi. As this Bug is now lying around for more than one month I decided to
look into a fix. It is not a very beautiful one, it is only partially
tested and it only works for systems which can fork, so please look over it
before applying it.
The idea is to fork off a process, change into the directory, make sure the
directory has the same inode which was originally used, and then change
permissions. fchmod would have been much easier.
A diff follows:
-- snip --
--- Path.pm 2005-02-08 13:23:10.000000000 +0100
+++ Path.pm.new 2005-02-08 17:13:04.000000000 +0100
@@ -189,7 +189,7 @@
} else {
$root =3D~ s#/\z##;
}
- (undef, undef, my $rp) =3D lstat $root or next;
+ (undef, my $ino, my $rp) =3D lstat $root or next;
$rp &=3D 07777; # don't forget setuid, setgid, sticky bits
if ( -d _ ) {
# notabene: 0700 is for making readable in the first place,
@@ -239,9 +239,25 @@
}
else {
- chmod($rp, ($Is_VMS ? VMS::Filespec:
))
+ # this avoids a race condition which would occur if someone
+ # replaced $root while we were working on it. I would have
+ # preferred to use fchmod, but this seems not to be
+ # supported in perl. -- AW
+ my($fork)=3Dfork;
+ if ($fork<0) {carp("and cannot fork: $!");}
+ elsif ($fork>0) { # parent
+ waitpid($fork,0);
+ } else { # child
+ chdir($root) or carp("and cannot change to $root: $!");
+ (undef,
+ $rino=3D=3D$ino or carp(
+ "and someone replaced $root while I was working on it\n=
");
+ $rino=3D=3D$ino
+ and chmod($rp,($Is_VMS ? VMS::Filespec:
"."))
+ exit(0);
+ }
}
}
else {=20
-- snip --
I hope this helps.
cu
AW
--=20
<ThePhonk> *tueteKlammernU
+Miststueck!
--h31gzZEtNLTqOjlF
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCCOVzYFo
il5C3ThxYhBD2Ua
=eTp1
-----END PGP SIGNATURE-----
--h31gzZEtNLTqO
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : Re: [vendor-sec] CAN-2004-0452 File::Path::rmtree() vulnerability | #18 |
On Fri, Feb 04, 2005 at 03:32:05PM +0100, Thierry Carrez wrote:
>Brendan O'Dea wrote:
>
>> Seems a pretty clean fix, I've applied this to Debian's 5.8.4-5 package.
>
>Paul Szabo brought to our attention that the fix for CAN-2004-0452 does
>not handle all race conditions cases 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.
>======
>
>Apparently discussion still rages on how this would best be fixed.
>Any clue ?
Well actually, discussion doesn't rage at all as to how this should be
fixed.
Basically it's been acknowledged as a problem, but one that requires
more than a trivial patch to rmtree to correct, so as such is currently
languishing until such time as rmtree is rewritten to remove the race
condition.
I was kind of hoping that someone else would tackle that task since I
don't really regard myself as a security expert and did't want to make
the problem worse by introducing new, different security issues with a
recursive implementation.
However in the absence of any alternate suggestion, I've appended a
first-cut rmtree replacement.
For the moment I've ignored the third argument entirely; tempted to do
so permanently.
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.
--bod
use strict;
use warnings;
use Carp;
use Cwd 'getcwd';
sub _rmtree;
sub _rmtree
{
my ($path, $prefix, $up, $up_dev, $up_ino, $verbose) = @_;
my ($dev, $ino) = lstat $path or return 0;
unless (-d _)
{
unlink $path or return 0;
print "unlink $prefix$path\n" if $verbose;
return 1;
}
chdir $path or return 0;
# avoid a race condition where a directory may be replaced by a
# symlink between the lstat and the chdir
my ($new_dev, $new_ino) = stat '.';
unless ("$new_
{
croak "Directory $prefix$path changed before chdir, aborting\n";
}
my $count = 0;
if (opendir my $dir, '.')
{
my $entry;
while (defined ($entry = readdir $dir))
{
next if $entry =~ /^\.\.?$/;
$count += _rmtree $entry, "$prefix$path/", '..', $dev, $ino,
$verbose;
}
closedir $dir;
}
# don't leave the caller in an unexpected directory
unless (chdir $up)
{
croak "Can't return to $up from $prefix$path ($!)\n";
}
# ensure that a chdir .. didn't take us somewhere other than
# where we expected (see CVE-2002-0435)
unless (($new_dev, $new_ino) = stat '.'
and "$new_dev:$new_ino" eq "$up_dev:$up_ino")
{
croak "Previous directory $up changed since entering $prefix$path\n";
}
if (rmdir $path)
{
print "rmdir $prefix$path\n" if $verbose;
$count++;
};
return $count;
}
sub rmtree
{
my ($p, $verbose) = @_;
$p = [] unless defined $p and length $p;
$p = [ $p ] unless ref $p;
my @paths = grep defined && length, @$p;
unless (@paths)
{
carp "No root path(s) specified\n";
r...
Debian Bug Importer (debzilla) wrote : | #19 |
Message-ID: <email address hidden>
Date: Sat, 12 Feb 2005 11:07:09 +1100
From: Brendan O'Dea <email address hidden>
To: Thierry Carrez <email address hidden>
Cc: <email address hidden>, Mark J Cox <email address hidden>,
Matt Zimmerman <email address hidden>, <email address hidden>, Perl5 Porters <email address hidden>,
Paul Szabo <email address hidden>, <email address hidden>
Subject: Re: [vendor-sec] CAN-2004-0452 File::Path:
On Fri, Feb 04, 2005 at 03:32:05PM +0100, Thierry Carrez wrote:
>Brendan O'Dea wrote:
>
>> Seems a pretty clean fix, I've applied this to Debian's 5.8.4-5 package.
>
>Paul Szabo brought to our attention that the fix for CAN-2004-0452 does
>not handle all race conditions cases 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.
>======
>
>Apparently discussion still rages on how this would best be fixed.
>Any clue ?
Well actually, discussion doesn't rage at all as to how this should be
fixed.
Basically it's been acknowledged as a problem, but one that requires
more than a trivial patch to rmtree to correct, so as such is currently
languishing until such time as rmtree is rewritten to remove the race
condition.
I was kind of hoping that someone else would tackle that task since I
don't really regard myself as a security expert and did't want to make
the problem worse by introducing new, different security issues with a
recursive implementation.
However in the absence of any alternate suggestion, I've appended a
first-cut rmtree replacement.
For the moment I've ignored the third argument entirely; tempted to do
so permanently.
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.
--bod
use strict;
use warnings;
use Carp;
use Cwd 'getcwd';
sub _rmtree;
sub _rmtree
{
my ($path, $prefix, $up, $up_dev, $up_ino, $verbose) = @_;
my ($dev, $ino) = lstat $path or return 0;
unless (-d _)
{
unlink $path or return 0;
print "unlink $prefix$path\n" if $verbose;
return 1;
}
chdir $path or return 0;
# avoid a race condition where a directory may be replaced by a
# symlink between the lstat and the chdir
my ($new_dev, $new_ino) = stat '.';
unless ("$new_
{
croak "Directory $prefix$path changed before chdir, aborting\n";
}
my $count = 0;
if (opendir my $dir, '.')
{
my $entry;
while (defined ($entry = readdir $dir))
{
next if $entry =~ /^\.\.?$/;
$count += _rmtree $entry, "$prefix$path/", '..', $dev, $ino,
$verbose;
}
closedir $dir;
}
# don't leave the caller in an unexpected directory
unless (chdir $up)
{
croak "Can't return to $up from $prefix$path ($!)\n";
}
# ensure that a chdir .. didn't take us somewhere other than
# where we expected (see CVE-2002-0435)
unless (($new_dev, $new_ino) = stat '.'
and "$new_dev:$new_ino" e...
In Debian Bug tracker #286905, Martin Schulze (joey-infodrom) wrote : Re: CAN-2004-0452 File::Path::rmtree() vulnerability | #20 |
This has been assigned CAN-2005-0448.
Regards,
Joey
--
Ten years and still binary compatible. -- XFree86
Please always Cc to me when replying to me on the lists.
Debian Bug Importer (debzilla) wrote : | #21 |
Message-ID: <email address hidden>
Date: Wed, 16 Feb 2005 19:40:02 +0100
From: Martin Schulze <email address hidden>
To: <email address hidden>
Subject: Re: CAN-2004-0452 File::Path:
This has been assigned CAN-2005-0448.
Regards,
Joey
--
Ten years and still binary compatible. -- XFree86
Please always Cc to me when replying to me on the lists.
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : Bug#286905: fixed in perl 5.8.4-7 | #22 |
Source: perl
Source-Version: 5.8.4-7
We believe that the bug you reported is fixed in the latest version of
perl, which is due to be installed in the Debian FTP archive:
libcgi-
to pool/main/
libperl-
to pool/main/
libperl-
to pool/main/
libperl-
to pool/main/
libperl5.
to pool/main/
libperl5.
to pool/main/
libperl5.
to pool/main/
perl-base_
to pool/main/
perl-base_
to pool/main/
perl-base_
to pool/main/
perl-debug_
to pool/main/
perl-debug_
to pool/main/
perl-debug_
to pool/main/
perl-doc_
to pool/main/
perl-modules_
to pool/main/
perl-suid_
to pool/main/
perl-suid_
to pool/main/
perl-suid_
to pool/main/
perl_5.
to pool/main/
perl_5.8.4-7.dsc
to pool/main/
perl_5.
to pool/main/
perl_5.
to pool/main/
perl_5.
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Brendan O'Dea <email address hidden> (supplier of updated perl package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Mon, 7 Mar 2005 10:22:01 +1100
Source: perl
Binary: perl-base libcgi-fast-perl libperl-dev perl-debug perl-modules perl libperl5.8 perl-suid perl-doc
Architecture: all i386 powerpc source sparc
Version: 5.8.4-7
Distribution: unstable
Urgency: low
Maintainer: Brendan O'Dea <email address hidden>
Changed-By: Brendan O'Dea <email address hidden>
Description:
libperl-dev - Perl library: development files
libperl5.8 - Shared Perl library
perl - Larry Wall's Practical Extraction and Report Language
perl-base - The Pathologically Eclectic Rubbish Lister
perl-debug - Debug-enabled Perl interpreter
perl-suid - ...
Debian Bug Importer (debzilla) wrote : | #23 |
Message-Id: <email address hidden>
Date: Mon, 07 Mar 2005 01:47:15 -0500
From: Brendan O'Dea <email address hidden>
To: <email address hidden>
Subject: Bug#286905: fixed in perl 5.8.4-7
Source: perl
Source-Version: 5.8.4-7
We believe that the bug you reported is fixed in the latest version of
perl, which is due to be installed in the Debian FTP archive:
libcgi-
to pool/main/
libperl-
to pool/main/
libperl-
to pool/main/
libperl-
to pool/main/
libperl5.
to pool/main/
libperl5.
to pool/main/
libperl5.
to pool/main/
perl-base_
to pool/main/
perl-base_
to pool/main/
perl-base_
to pool/main/
perl-debug_
to pool/main/
perl-debug_
to pool/main/
perl-debug_
to pool/main/
perl-doc_
to pool/main/
perl-modules_
to pool/main/
perl-suid_
to pool/main/
perl-suid_
to pool/main/
perl-suid_
to pool/main/
perl_5.
to pool/main/
perl_5.8.4-7.dsc
to pool/main/
perl_5.
to pool/main/
perl_5.
to pool/main/
perl_5.
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Brendan O'Dea <email address hidden> (supplier of updated perl package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Mon, 7 Mar 2005 10:22:01 +1100
Source: perl
Binary: perl-base libcgi-fast-perl libperl-dev perl-debug perl-modules perl libperl5.8 perl-suid perl-doc
Architecture: all i386 powerpc source sparc
Version: 5.8.4-7
Distribution: unstable
Urgency: low
Maintainer: Brendan O'Dea <email address hidden>
Changed-By: Brendan O'Dea <email address hidden>
Description:
libperl-dev - Perl library: development files
libperl5.8 - S...
Martin Pitt (pitti) wrote : | #24 |
Fixed Warty in USN-94-1:
perl (5.8.4-6ubuntu1) hoary; urgency=low
.
* SECURITY UPDATE:
* lib/File/Path.pm: Stole patch from Debian revision, original changelog:
SECURITY [CAN-2005-0448]: rewrite File::Path::rmtree to avoid race
condition which allows an attacker with write permission on
directories in the tree being removed to make files setuid or to
remove arbitrary files (closes: #286905, #286922). Supersedes
the previous patch for CAN-2004-0452.
Fix for Hoary is ready, but deferred until after the preview release.
Martin Pitt (pitti) wrote : | #25 |
(In reply to comment #13)
> Fix for Hoary is ready, but deferred until after the preview release.
Uploaded now.
In Debian Bug tracker #286905, Micah Anderson (micah-debian) wrote : CAN-2005-0448 and woody | #26 |
reopen 286905
tag 286905 + woody
thanks
As noted on debian-security:
#286905 fixes CAN-2005-0448 for testing's perl (5.8.4-7), however it
leaves it unfixed in stable's version (5.6.1-8.8), which is also
affected (according to http://
this bug should not be closed.
Debian Bug Importer (debzilla) wrote : | #27 |
Message-ID: <email address hidden>
Date: Thu, 17 Mar 2005 23:37:48 -0600
From: Micah Anderson <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: CAN-2005-0448 and woody
--ed/6oDxOLijJh8b0
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reopen 286905
tag 286905 + woody
thanks
As noted on debian-security:
#286905 fixes CAN-2005-0448 for testing's perl (5.8.4-7), however it
leaves it unfixed in stable's version (5.6.1-8.8), which is also
affected (according to http://
this bug should not be closed.=20
--ed/6oDxOLijJh8b0
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCOmks9n4
eFDprsdPBoTmbgp
=uNwJ
-----END PGP SIGNATURE-----
--ed/6oDxOLijJh
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : Re: Bug#286905: CAN-2005-0448 and woody | #28 |
On Thu, Mar 17, 2005 at 11:37:48PM -0600, Micah Anderson wrote:
>#286905 fixes CAN-2005-0448 for testing's perl (5.8.4-7), however it
>leaves it unfixed in stable's version (5.6.1-8.8), which is also
>affected (according to http://
>this bug should not be closed.
I've sent a new source package to the security team.
--bod
Debian Bug Importer (debzilla) wrote : | #29 |
Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 12:51:46 +1100
From: Brendan O'Dea <email address hidden>
To: Micah Anderson <email address hidden>, <email address hidden>
Subject: Re: Bug#286905: CAN-2005-0448 and woody
On Thu, Mar 17, 2005 at 11:37:48PM -0600, Micah Anderson wrote:
>#286905 fixes CAN-2005-0448 for testing's perl (5.8.4-7), however it
>leaves it unfixed in stable's version (5.6.1-8.8), which is also
>affected (according to http://
>this bug should not be closed.
I've sent a new source package to the security team.
--bod
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : Fixed in NMU of perl 5.6.1-8.9 | #30 |
tag 286905 + fixed
tag 286922 + fixed
quit
This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Fri, 18 Mar 2005 22:22:25 +1100
Source: perl
Binary: perl-suid perl-modules perl perl-debug perl-base libperl5.6 perl-doc libperl-dev libcgi-fast-perl
Architecture: source i386 all
Version: 5.6.1-8.9
Distribution: stable-security
Urgency: high
Maintainer: Martin Schulze <email address hidden>
Changed-By: Brendan O'Dea <email address hidden>
Description:
libcgi-fast-perl - CGI::Fast Perl module.
libperl-dev - Perl library: development files.
libperl5.6 - Shared Perl library.
perl - Larry Wall's Practical Extraction and Report Language.
perl-base - The Pathologically Eclectic Rubbish Lister.
perl-debug - Debug-enabled Perl interpreter.
perl-doc - Perl documentation.
perl-modules - Core Perl modules.
perl-suid - Runs setuid Perl scripts.
Closes: 286905 286922
Changes:
perl (5.6.1-8.9) stable-security; urgency=high
.
* SECURITY [CAN-2005-0448]: rewrite File::Path::rmtree to avoid race
condition which allows an attacker with write permission on
directories in the tree being removed to make files setuid or to
remove arbitrary files (closes: #286905, #286922). Supersedes
the previous patch for CAN-2004-0452.
Files:
bf8f434e157f15
5f8583904c8f26
2516eb570a001c
d2ccba71035e7b
ba2dbf867e05ce
46ad051a8314ca
d32af3c6b91456
2d35d5c7bf825e
e896258f9bab36
325554fce57546
7eb6c4b69d60aa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCO8tUW5q
wyU+9UfHXziR0oD
=VMJ1
-----END PGP SIGNATURE-----
Debian Bug Importer (debzilla) wrote : | #31 |
Message-Id: <email address hidden>
Date: Tue, 22 Mar 2005 06:02:30 -0500
From: Brendan O'Dea <email address hidden>
To: <email address hidden>
Cc: Brendan O'Dea <email address hidden>, Martin Schulze <email address hidden>
Subject: Fixed in NMU of perl 5.6.1-8.9
tag 286905 + fixed
tag 286922 + fixed
quit
This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Fri, 18 Mar 2005 22:22:25 +1100
Source: perl
Binary: perl-suid perl-modules perl perl-debug perl-base libperl5.6 perl-doc libperl-dev libcgi-fast-perl
Architecture: source i386 all
Version: 5.6.1-8.9
Distribution: stable-security
Urgency: high
Maintainer: Martin Schulze <email address hidden>
Changed-By: Brendan O'Dea <email address hidden>
Description:
libcgi-fast-perl - CGI::Fast Perl module.
libperl-dev - Perl library: development files.
libperl5.6 - Shared Perl library.
perl - Larry Wall's Practical Extraction and Report Language.
perl-base - The Pathologically Eclectic Rubbish Lister.
perl-debug - Debug-enabled Perl interpreter.
perl-doc - Perl documentation.
perl-modules - Core Perl modules.
perl-suid - Runs setuid Perl scripts.
Closes: 286905 286922
Changes:
perl (5.6.1-8.9) stable-security; urgency=high
.
* SECURITY [CAN-2005-0448]: rewrite File::Path::rmtree to avoid race
condition which allows an attacker with write permission on
directories in the tree being removed to make files setuid or to
remove arbitrary files (closes: #286905, #286922). Supersedes
the previous patch for CAN-2004-0452.
Files:
bf8f434e157f15
5f8583904c8f26
2516eb570a001c
d2ccba71035e7b
ba2dbf867e05ce
46ad051a8314ca
d32af3c6b91456
2d35d5c7bf825e
e896258f9bab36
325554fce57546
7eb6c4b69d60aa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCO8tUW5q
wyU+9UfHXziR0oD
=VMJ1
-----END PGP SIGNATURE-----
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : closing 286905 | #32 |
# Automatically generated email from bts, devscripts version 2.8.11
close 286905
Debian Bug Importer (debzilla) wrote : | #33 |
Message-Id: <email address hidden>
Date: Thu, 24 Mar 2005 11:47:07 +1100
From: Brendan O'Dea <email address hidden>
To: <email address hidden>
Subject: closing 286905
# Automatically generated email from bts, devscripts version 2.8.11
close 286905
In Debian Bug tracker #286905, Brendan O'Dea (bod) wrote : Fixed in NMU of perl 5.6.1-8.9 | #34 |
tag 286905 + fixed
tag 286922 + fixed
quit
This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Fri, 18 Mar 2005 22:22:25 +1100
Source: perl
Binary: perl-suid perl-modules perl perl-debug perl-base libperl5.6 perl-doc libperl-dev libcgi-fast-perl
Architecture: source i386 all
Version: 5.6.1-8.9
Distribution: stable-security
Urgency: high
Maintainer: Martin Schulze <email address hidden>
Changed-By: Brendan O'Dea <email address hidden>
Description:
libcgi-fast-perl - CGI::Fast Perl module.
libperl-dev - Perl library: development files.
libperl5.6 - Shared Perl library.
perl - Larry Wall's Practical Extraction and Report Language.
perl-base - The Pathologically Eclectic Rubbish Lister.
perl-debug - Debug-enabled Perl interpreter.
perl-doc - Perl documentation.
perl-modules - Core Perl modules.
perl-suid - Runs setuid Perl scripts.
Closes: 286905 286922
Changes:
perl (5.6.1-8.9) stable-security; urgency=high
.
* SECURITY [CAN-2005-0448]: rewrite File::Path::rmtree to avoid race
condition which allows an attacker with write permission on
directories in the tree being removed to make files setuid or to
remove arbitrary files (closes: #286905, #286922). Supersedes
the previous patch for CAN-2004-0452.
Files:
bf8f434e157f15
5f8583904c8f26
2516eb570a001c
d2ccba71035e7b
ba2dbf867e05ce
46ad051a8314ca
d32af3c6b91456
2d35d5c7bf825e
e896258f9bab36
325554fce57546
7eb6c4b69d60aa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCO8tUW5q
wyU+9UfHXziR0oD
=VMJ1
-----END PGP SIGNATURE-----
Debian Bug Importer (debzilla) wrote : | #35 |
Message-Id: <email address hidden>
Date: Fri, 15 Apr 2005 18:19:59 -0400
From: Brendan O'Dea <email address hidden>
To: <email address hidden>
Cc: Brendan O'Dea <email address hidden>, Martin Schulze <email address hidden>
Subject: Fixed in NMU of perl 5.6.1-8.9
tag 286905 + fixed
tag 286922 + fixed
quit
This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Fri, 18 Mar 2005 22:22:25 +1100
Source: perl
Binary: perl-suid perl-modules perl perl-debug perl-base libperl5.6 perl-doc libperl-dev libcgi-fast-perl
Architecture: source i386 all
Version: 5.6.1-8.9
Distribution: stable-security
Urgency: high
Maintainer: Martin Schulze <email address hidden>
Changed-By: Brendan O'Dea <email address hidden>
Description:
libcgi-fast-perl - CGI::Fast Perl module.
libperl-dev - Perl library: development files.
libperl5.6 - Shared Perl library.
perl - Larry Wall's Practical Extraction and Report Language.
perl-base - The Pathologically Eclectic Rubbish Lister.
perl-debug - Debug-enabled Perl interpreter.
perl-doc - Perl documentation.
perl-modules - Core Perl modules.
perl-suid - Runs setuid Perl scripts.
Closes: 286905 286922
Changes:
perl (5.6.1-8.9) stable-security; urgency=high
.
* SECURITY [CAN-2005-0448]: rewrite File::Path::rmtree to avoid race
condition which allows an attacker with write permission on
directories in the tree being removed to make files setuid or to
remove arbitrary files (closes: #286905, #286922). Supersedes
the previous patch for CAN-2004-0452.
Files:
bf8f434e157f15
5f8583904c8f26
2516eb570a001c
d2ccba71035e7b
ba2dbf867e05ce
46ad051a8314ca
d32af3c6b91456
2d35d5c7bf825e
e896258f9bab36
325554fce57546
7eb6c4b69d60aa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCO8tUW5q
wyU+9UfHXziR0oD
=VMJ1
-----END PGP SIGNATURE-----
Changed in perl: | |
status: | Unknown → Fix Released |
Automatically imported from Debian bug report #286905 http:// bugs.debian. org/286905