insecure dependency open while running setgid

[David K. Wall]

I am having the same error message
insecure dependency open while running setgid
as another user on tripod ( i am quoting the old post at the end
of this message)
i believe the problem is as Bart points out
"that the name of the file-to-open is simply copied from
one of the CGI parameters"
but that's how i get the file name, from cgi input.

Don't do that. Bart (Lateur?) is right, this is a horrible security
hole.

so from Bart's and others posts i understand that the filename is
tainted.
my question is : what could i do to untaint it, as i have very
limited priviliges on a shared server- tripod
i was not able to fully understand Bart's last paragraph when he
says "choose one of a few possibilities for file names in
a hash"

Something like the following.



#!/usr/bin/perl -wT
use strict;
use CGI;

# use a hash to store filenames
# hash keys are in the HTML form
# hash values are the real path/filenames
my %datafiles = (
file1 => '/path/data1',
file2 => '/path/data2'
);

my $selected = param('filename_from_CGI_form');
my $file;
if ( defined $datafiles{$selected} ) {
$file = $datafiles{$selected};
}
else {
# maybe set a default $file, or
# output an error message and exit
}
open FILE, '<', $file or
die "Cannot open data file, user chose $selected: $!";

# ...

[Alan J. Flavell]

so from Bart's and others posts i understand that the filename is
tainted.
my question is : what could i do to untaint it, as i have very
limited priviliges on a shared server- tripod

Is it not obvious that you are allowing the client complete control of
the file-path specification on your server? That's a massive security
hole! Taint-checking has wisely alerted you to the problem. The
important thing at this point is to solve the problem, NOT just to
mark the filepath as untainted and go blissfully about your
business...

Even if you could be sure to clobber all of the characters which allow
them to change directories, create pipes to powerful commands, and so
on, you would still be allowing them free rein (or should that be
"reign" in this case...?) over a part of your filesystem.

i was not able to fully understand Bart's last paragraph when he
says "choose one of a few possibilities for file names in a hash"

I feel sure he is suggesting that you pre-define a list of the files
which you are going to permit to participate in the action, and that
you only allow the client to specify one of those, and reject anything
else. That could be conveniently done by listing the permitted file
names in a hash.

Of course, whether that's an acceptable solution depends on what
exactly you want to do. I don't recall the original question, so I'll
leave that part open.