Re: Insecure dependency on perl module

A couple of quick things ...

Having a look at the source to File::Path it appears, that your code is carping when attempting to perform the unlink. eg.

233                 unless (unlink $root) {
234                     carp "Can't unlink file $root: $!";
235                     if ($force_writeable) {
236                         chmod $rp, $root
237                             or carp("and can't restore permissions
+ to "
238                                     . sprintf("0%o",$rp) . "\n");
239                     }
240                     last;
241                 }
[download]

It might be worth posting a little bit of code to see how you are cleaning up the file name that you are sending to File::Path::rmtree. Also too, have you cleaned up your PATH environment variable prior to the calling of the File::Path::rmtree function?

Ooohhh, Rob no beer function well without!

Comment on Re: Insecure dependency on perl module Select or Download Code

Replies are listed 'Best First'.
Re: Re: Insecure dependency on perl module by hotshot (Prior) on Nov 19, 2001 at 12:53 UTC
Hotshot thanks for your answer. my launder code is : `if ($path =~ /^([-\@\w.\/\s]+)$/) { $path = $1; } else { die "Bad path in $path"; }` [download] and about your suggestion to clean the path, I never had to do this before with perl functions (always with system commands), did you ment soething like that: `$ENV{PATH} = '/usr/lib/perl5/5.6.1/File/'; ?` [download] thanks 2001-11-19 Edit by Corion : Added formatting	[reply] [d/l] [select]
Re: Re: Re: Insecure dependency on perl module by rob_au (Abbot) on Nov 19, 2001 at 17:14 UTC
As it is, you find that your data is still tainted after with that regular expression - This is because of the 'valid' parsing of the '`/`' character by your regular expression. To correctly untaint data, you need to exclude everything except "word" characters (alphabetics, numerics and underscores), hyphens, at characters and a single dot - The inclusion of the forward-slash character allows data to remain tainted because it is exceptionally easy for parsed data to reference files outside the 'permitted scope' of your application - For example, if your routine was supposed to allow the deletion of trees under the directory `/home/<user-entered-directory>`, a maligned user could easily pervert this code by entering `/etc` and causing great harm to your system. The recommended regular expression for untainting data (from perlsec) would be: `if ($data =~ /^([-\@\w.]+)$/) { $data = $1; # $data now untainted } else { die "Bad data in $data"; # log this somewhere }` [download] This may however mean that you will have to modify your code to run under `-T` and possibly a `chroot` environment or else you could have potentially nasty users causing harm to your system. Have a read through the "Laundering and Detecting Tainted Data" and "Cleaning Up Your Path" sections of perlsec. Update - See davorg's post here for an update on this problem. Ooohhh, Rob no beer function well without!	[reply] [d/l] [select]