Taint mode help

[Dave Saville]

One of my cgi scripts is throwing:

Insecure dependency in chdir while running with -t switch at
d:/usr/lib/perl/lib/5.8.2/File/Find.pm line 814., referer:
*cgi-bin/upload.pl

I know how to fix this if it were in my code but in the supplied
modules? I must be missing something :-)

I am not passing anything to find. I chdir to a hard coded directory
and then find(&wanted, '.');
--
Regards
Dave Saville

[Ben Morrow]

Quoth "Dave Saville" <da...@invalid.invalid>:

> One of my cgi scripts is throwing:
>
> Insecure dependency in chdir while running with -t switch at
> d:/usr/lib/perl/lib/5.8.2/File/Find.pm line 814., referer:
> *cgi-bin/upload.pl

-t and not -T? That's a bad idea for a CGI script. So is using 5.8.2,
which is 9 years old now and entirely unsupported.

> I know how to fix this if it were in my code but in the supplied
> modules? I must be missing something :-)
>
> I am not passing anything to find. I chdir to a hard coded directory
> and then find(&wanted, '.');

See either the no_chdir option or the untaint* options to File::Find.

Ben

[Randal L. Schwartz]

>>>>> "Dave" == Dave Saville <da...@invalid.invalid> writes:

Dave> I am not passing anything to find. I chdir to a hard coded directory
Dave> and then find(&wanted, '.');

Give find() the full hardcoded path then. It's very likely taint mode
is upset by the response from trying to turn '.' into an absolute path,
since it involves values "from the outside".

print "Just another Perl hacker,"; # the original

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

[Ben Morrow]

Quoth mer...@stonehenge.com (Randal L. Schwartz):

> >>>>> "Dave" == Dave Saville <da...@invalid.invalid> writes:
>
> Dave> I am not passing anything to find. I chdir to a hard coded directory
> Dave> and then find(&wanted, '.');
>
> Give find() the full hardcoded path then. It's very likely taint mode
> is upset by the response from trying to turn '.' into an absolute path,
> since it involves values "from the outside".

No, it's simpler than that: find (without no_chdir) chdirs into each
directory as it recurses down. Since those directory names came from
readdir, they are tainted, and you can't pass them back to chdir without
untainting them. This may seem a little silly, but that's the way it is.

(I'm not actually certain there isn't some way, on some system, of
arranging for readdir to return something which chdir will misinterpret.
ISTR, for instance, that it's possible for a misconfigured Samba server
to return directory names with / in, and Windows will happily pass them
back to the application but then chdir to the wrong place when you try
to enter the directory. I may be misremembering, though.)

Ben

[Randal L. Schwartz]

>>>>> "Ben" == Ben Morrow <b...@morrow.me.uk> writes:

Ben> No, it's simpler than that: find (without no_chdir) chdirs into
Ben> each directory as it recurses down. Since those directory names
Ben> came from readdir, they are tainted, and you can't pass them back
Ben> to chdir without untainting them. This may seem a little silly, but
Ben> that's the way it is.

Ahh, thanks for that. Haven't had as much experience with taint as most
people attribute to me. :)

[Dave Saville]

On Thu, 10 May 2012 20:56:32 UTC, Ben Morrow <b...@morrow.me.uk> wrote:

>
> Quoth "Dave Saville" <da...@invalid.invalid>:
> > One of my cgi scripts is throwing:
> >
> > Insecure dependency in chdir while running with -t switch at
> > d:/usr/lib/perl/lib/5.8.2/File/Find.pm line 814., referer:
> > *cgi-bin/upload.pl
>
> -t and not -T? That's a bad idea for a CGI script. So is using 5.8.2,
> which is 9 years old now and entirely unsupported.
>

-t Ooops a forgotton switch. Well spotted thanks. Ages ago I had a
problem in turning taint mode on at all with Apache. Our port barfs on
*any* command line switches for perl. I got around it by using the
PERL5OPT environmental in the script that starts apache. You need to
ensure it is in the list of passed environmentals though. I set it to
-t to catch anything I may have missed in testing - you know what
users are like :-) - seeing as it had been running without a taint
check at all for some time it did not seem any worse. And of course I
forgot all about it. 5.8.2 happens to be the latest that actually
works on my platform and if it ain't broke...... The latest port has a
heap of problems that are yet to be resolved. :-(

> > I know how to fix this if it were in my code but in the supplied
> > modules? I must be missing something :-)
> >
> > I am not passing anything to find. I chdir to a hard coded directory
> > and then find(&wanted, '.');
>
> See either the no_chdir option or the untaint* options to File::Find.
>

Thanks - no_chdir is perfect. Did not even need to touch the "wanted"
code as I was working with FQNs anyway. :-)
--
Regards
Dave Saville

[Rainer Weikusat]

Ben Morrow <b...@morrow.me.uk> writes:

[...]

> (I'm not actually certain there isn't some way, on some system, of
> arranging for readdir to return something which chdir will
> misinterpret.

If the directory is writeable by someone interested in devising
mischief, what readdir returns as the name of a directory and
possibly, what a following stat configirmed as such, may well be a
symlink to a completely different part of the filesystem by the time
chdir interprets it.

[Ben Morrow]

Quoth "Dave Saville" <da...@invalid.invalid>:

> On Thu, 10 May 2012 20:56:32 UTC, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth "Dave Saville" <da...@invalid.invalid>:
> > > One of my cgi scripts is throwing:
> > >
> > > Insecure dependency in chdir while running with -t switch at
> > > d:/usr/lib/perl/lib/5.8.2/File/Find.pm line 814., referer:
> > > *cgi-bin/upload.pl
> >
> > -t and not -T? That's a bad idea for a CGI script. So is using 5.8.2,
> > which is 9 years old now and entirely unsupported.
>
> -t Ooops a forgotton switch. Well spotted thanks.

Heh. These things happen... :)

> 5.8.2 happens to be the latest that actually
> works on my platform and if it ain't broke...... The latest port has a
> heap of problems that are yet to be resolved. :-(

What platform are you on? If you're interested in getting a more recent
perl to build I'd be happy to try and walk you through it.

Ben

[Peter J. Holzer]

On 2012-05-10 22:15, Ben Morrow <b...@morrow.me.uk> wrote:
> (I'm not actually certain there isn't some way, on some system, of
> arranging for readdir to return something which chdir will misinterpret.
> ISTR, for instance, that it's possible for a misconfigured Samba server
> to return directory names with / in,

On a system where / isn't the directory separator (like MacOS <= 9 or
VMS)? Does Samba run on these systems? It may be be possible to get samba
to return filenames with "\" in it verbatim, though.

There was also a similar problem with the original Sun NFS server: The
NFS protocol avoided the problem of different path separators by never
sending a path over the network - you only send components. So if a Unix
client wants to create a file "/foo/bar/baz", it doesn't send a request
«create file "/foo/bar/baz"» - instead it aquires the directory handle
of "/foo/bar" and then sends a request «create file $dirhandle, "baz"».
Now what happened when a client sent a request «create file $dirhandle,
"ba/zoom"» (which could happen with non-Unix NFS clients)? The NFS
server was part of the kernel, and it called all the low-level file
handling functions directly - functions which were written on the
assumption that a path component could never contain a / because all the
system calls treat / as a separator. So the NFS server could create a
directory entry with an embedded /. Readdir of course returned the / in
the entry, but there was no way to access the file from SunOS, since all
the system calls (open, unlink, ...) interpreted the / as a separator.
(I don't remember whether it was still accessible by NFS).

hp



--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Dave Saville]

On Fri, 11 May 2012 21:36:08 UTC, Ben Morrow <b...@morrow.me.uk> wrote:

<snip>

> What platform are you on? If you're interested in getting a more recent
> perl to build I'd be happy to try and walk you through it.
>
>

OS/2 :-) There have been working later ports but I never got around to
updating. What I had works and to me changing the version of perl is
not a trivial matter if you have a lot of installed modules. I also
don't have access to the required patches although I could get them I
think.

At the moment I am really in a hole because I need a couple of modules
that need compiling and unless you have the *exact* same
setup/environment as the porter (binary distro) then nothing compiles.
OS/2 although it has lots of unixy features the one thing they did not
copy was the file system so it suffers from DOS drive letters to add
to the fun :-( Amongst other things the current port can't get the
path substitution correct. ie if it was built to say x:/perl5 and you
want it in y:/usr/lib/perl or even y:/perl5 by means of the
PERLLIB_PREFIX environmental than it screws the path up and then can't
find anything. Another problem, which may be related, is that if it
tries to compile something it can't find *.h files that are clearly on
the drive. But there is only one guy porting and I have to wait until
he gets around to looking at it. I have looked at building it myself
before but there are *so* many other libraries etc. it expects to find
that I gave up.

Thanks for the offer though.
--
Regards
Dave Saville

[Shmuel Metz]

In <fV45K0OBJxbE-pn2-4yg05oBtBKS3@localhost>, on 05/12/2012
at 10:57 AM, "Dave Saville" <da...@invalid.invalid> said:

>OS/2 :-)

What release? 5.8.8 worked fine for me on a current OS/2 and I'm
currently using 5.10; 5.14 sort of works but the remapping for
PERLLIB_PREFIX is truncating file names.

I've had good luck installing CPAN modules on eCS 2.0 using Perl 5.10
and Paul Smedley's build environment.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Dave Saville]

On Wed, 16 May 2012 01:43:33 UTC, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:

> In <fV45K0OBJxbE-pn2-4yg05oBtBKS3@localhost>, on 05/12/2012
> at 10:57 AM, "Dave Saville" <da...@invalid.invalid> said:
>
> >OS/2 :-)
>
> What release? 5.8.8 worked fine for me on a current OS/2 and I'm
> currently using 5.10; 5.14 sort of works but the remapping for
> PERLLIB_PREFIX is truncating file names.
>

ECS 2.1 and 5.8.2. Yeah, truncation and other things. I don't want to
do 5.8.2 to 5.10 and then have to do it all again for 5.14 when (if)
it is fixed

> I've had good luck installing CPAN modules on eCS 2.0 using Perl 5.10
> and Paul Smedley's build environment.
>

Does that include C compiles?


--
Regards
Dave Saville

[Shmuel Metz]

In <fV45K0OBJxbE-pn2-QwdCe1W8edL9@localhost>, on 05/16/2012

at 07:20 PM, "Dave Saville" <da...@invalid.invalid> said:

>ECS 2.1 and 5.8.2. Yeah, truncation and other things.

I never saw truncation on either 5,8,2 or 5,8.8, only on 5.14.

>Does that include C compiles?

Yes. Several of the CPAN packages I installed on 5.10 included C code.