Re: disable taint for just one sub
by MZSanford (Curate) on Jul 23, 2001 at 17:54 UTC
|
I do not think you can disable taint checking, but you can untaint a variable by matching it into a regex, and using $1. So, if you must subvert taint checking, a function like the following would let you untaint the variables you are going to (eventually) use for the bind() call :
sub untaint {
my (@refs) = @_;
my $cnt++;
foreach my $RvSv (@refs) {
${$RvSv} =~ m/^.*$/;
${$RvSv} = $1;
$cnt++;
}
return($cnt);
}
## use as
$untained_count = untaint(\$a,\$b);
although, i would suggest actually using the regex to check that the data is valid (be it numeric, string, or whatever) ... thats what taint checking is for, and why the regex works.
remeber the immortal word's of Socrates who said, "I drank what ?" | [reply] [d/l] [select] |
|
|
I believe the problem khippy is running into is using external modules that are not Taint-safe. I do not personally have guidance for him on what to do about this, though one thought is to pester the author to make their module taint-safe, or better yet, offer to help them do this.
| [reply] |
|
|
You could instantiate that object in another process by using Windows Script Components.
| [reply] |
|
|
I am very sorry, but I can't image how to build that code into the following structure of Net::Print:
Use Net::Printer;
# Create new Printer Object
$lineprinter = new Net::Printer(
use Net::Printer;
# Create new Printer Object
$lineprinter = new Net::Printer(
filename=>"/home/jdoe/myfile.txt",
printer => "lp",
server => "printserver",
port => 515,
lineconvert => "YES"
);
# Print the file
$result = $lineprinter->printfile();
I'd appreciate any help concerning that.
there are no silly questions
killerhippy | [reply] [d/l] |
|
|
You'll have to figure out where in Net::Printer it is inheriting the tainted data, as it is not from your calls to the Net::Printer methods-- I assume you are untainting things before you use them. Probably Net::Printer is using an environement variable or two. You have then three choices, either set the specific $ENV{key} from within your script, or auto-detaint all $ENV{keys} using the methods shown in the other writeups in this node wrapped in foreach my $key (keys %ENV) {...} , or rewrite the module to be taint-safe.
| [reply] [d/l] |
Re: disable taint for just one sub
by wine (Scribe) on Jul 23, 2001 at 18:36 UTC
|
From perlsec: Once taint mode is on, it's on for
the remainder of your script.
So, alas. Perlsec also describes how to "launder" tainted data:
Here's a test to make sure that the data contains nothing
but "word" characters (alphabetics, numerics, and under
scores), a hyphen, an at sign, or a dot.
if ($data =~ /^([-\@\w.]+)$/) {
$data = $1; # $data now untainted
} else {
die "Bad data in $data"; # log this somewhere
}
This is fairly secure because "/\w+/" doesn't normally
match shell metacharacters, nor are dot, dash, or at going
to mean something special to the shell. Use of "/.+/"
would have been insecure in theory because it lets every
thing through, but Perl doesn't check for that. The les
son is that when untainting, you must be exceedingly care
ful with your patterns. Laundering data using regular
expression is the only mechanism for untainting dirty
data, unless you use the strategy detailed below to fork a
child of lesser privilege.
| [reply] [d/l] |
Re: disable taint for just one sub
by grinder (Bishop) on Jul 23, 2001 at 19:35 UTC
|
Lots of good advice given so far. The only thing I would add would be that you could try and explicitly set your PATH and IFS environment variables, and clean out other naughty variables (this last idea pinched directly from perlsec).
$ENV{PATH} = '/bin:/usr/bin';
$ENV{IFS} = '';
delete @ENV{qw/CDPATH ENV BASH_ENV/};
--g r i n d e r
| [reply] [d/l] |
Re: disable taint for just one sub
by converter (Priest) on Jul 23, 2001 at 20:17 UTC
|
It would be very helpful if you would include the "insecure dependency" (and any other warning) message perl prints. Maybe you can untaint the offending variable in your code, but it's hard to tell without knowing what perl is complaining about.
| [reply] |
|
|
as requested (sorry for forgetting it) here's the errormessage netscape gives, because of `use CGI::Carp qw/fatalsToBrowser/;`:
Content-type: text/html
Software error:
Insecure dependency in bind while running with -T switch at /usr/local
+/lib/perl5/site_perl/5.6.1/Net/Printer.pm line 534.
It's the same, what apache's log file says:
[Tue Jul 24 11:30:17 2001] addXmail.pl: Insecure dependency in bind wh
+ile running with -T switch at /usr/local/lib/perl5/site_perl/5.6.1/Ne
+t/Printer.pm line 534
The script ist invocing the module by `$result = $lineprinter->printfile();' with the variables defined before (take a look above!), which is calling the module above, here is what the concerning line 534 of the module tries:
if (!(bind($sh, $this))) {
return "Printer: Error: Cannot bind socket: $!\n";
} # if !bind($sh, $this)
I don't have any idea, what bind does. Have you?
there are no silly questions
killerhippy | [reply] [d/l] [select] |
|
|
bind() binds a keymap to a readline function or macro (so sayeth the BASH info pages anyway-- I've never used it). My guess is that the module is picking up values for $sh or $this from the environment or from system calls at some point in the process. And indeed looking at the source for Net::Printer verifies something like this is happening.
In at least one spot it is relying on assigning the return value from a backticked `hostname` command (both in the OpenSocket and printfile functions). My suggestion would be to fork the Net::Printer module for your local install (just give it a new name and put it in the directory with your script and use as you would any other of your own modules). You can then go through and either hardcode the correct results for these system calls or add taint checking (for valid hostname returned values) (or just detaint the $hostname variables without checking them-- it seems to me that anyone who can cause an insecure hostname return value has already compromised the system).
If you manage to get a taint-safe version made without hardcoding your hostname into the script, consider sending a patch to the package maintainer.
UPDATE: ariels is right, and I am officially red-faced about it. The bind in use by Net::Printer is something else entirely from what I described, but it still sounds like a thinly veiled system call to me (this socket binding stuff). As such it would be dangerous to do it with tainted inputs, and the crux of your problem remains the same, either replace the system call to hostname with hardcoded data, introduce hostname detainting into the module, or simply replace the backticked system call with "use Sys::Hostname; my $hostname = hostname();".
| [reply] |
|
|
|
|
|