…is taint mode not the default in wide use…
Not in my experience. :( And when arguing against the practice, and discovering 100s of scripts have to be fixed (some in rather deep ways) with it on, the wide spread manager will say: “We can’t afford to do anything about that right now.”
| [reply] |
Taint has wide usage, but it only limits passing certain environmental variables through. If the CGI request sets BAD_VAR = rm -rf /, Perl will happily pass that through to your executable without untainting because it doesn't expect your child process will use it (in my understanding).
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
| [reply]
[d/l] |
Perhaps I don't understand the parent node as it was intended, but if I do correctly grok it, I think it's misleading, at best.
Oversimplifying a bit, when the -T CLI option is on, anything that comes from outside the script is "tainted."
Untainting data (be it ENV, $vars or anything else) can be fairly easy... but often is anything but 'easy' or simple. Consider, for example, data received as input from a form on a website.
However, take a simple case, where login_data (an ID and yeah, this is old) was supposed to be five digits -- no more, no less, and nothing that's not an (arabic) digit. Since the user entry is tainted, the cgi in use untaints the login_data (to the site owner's satisfaction) by checking that the id received consists of exactly five digits:
unless ( $value =~ /^\d{5}$/ ) # UNTAINT
{
out_badlog();
warn ("bad after UNTAINT\n");
exit;
}
Ascertaining that the five digits comprise a valid ID is a different topic and is performed in another part of the script.
So, moving on to this from perlsec:
"SECURITY MECHANISMS AND CONCERNS
Taint mode
Perl automatically enables a set of special security checks, called
*taint mode*, when it detects its program running with differing real
and effective user or group IDs. The setuid bit in Unix permissions is
mode 04000, the setgid bit mode 02000; either or both may be set. You
can also enable taint mode explicitly by using the -T command line flag.
This flag is *strongly* suggested for server programs and any program
run on behalf of someone else, such as a CGI script."
perlsec offers much more of relevance to the immediately previous comment from kennethk.
There's more in perlfaq7.pod about determining "if a variable (emphasis supplied) is tainted" ...after which pf7 offers these gems:
" You can use the tainted() function of the Scalar::Util module,
....See also 'Laundering and Detecting Tainted Data' in perlsec."
Frankly, I (for just one, I hope) was unaware (because of far too cursory reading of its docs) that S:C offered capabilities there. I hope this belated epiphany is useful to others.
Updated: Para 1 added and paras 2,3 and 4 edited for clarity
| [reply]
[d/l]
[select] |
I think you misapprehended my point (or I misapprehend yours). Suppose the client request to a Perl script sets the environmental variable BAD_VAR. In Perl, $ENV{BAD_VAR} is tainted. Suppose your CGI script is
#!/usr/bin/perl -wT
print "Content-type: text/plain\n\n";
local $ENV{PATH} = '/usr/local/bin';
print `my_prog 12345`;
From my understanding, Perl will not raise any issue in the scenario where my_prog accesses BAD_VAR, and hence %ENV can be used to bypass taint. Is this not correct?
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
| [reply]
[d/l]
[select] |
