How to turn off taint checking in cgi

Discussion in 'Perl Misc' started by Lars Eighner, Jul 10, 2007.

  1. Lars Eighner

    Lars Eighner Guest

    How can I turn off taint checking in a perl cgi script?

    I mean completely including path checking.

    Naturally I would like to do this on a per script basis, but if that
    is not possible, is it possible to compile perl (5.8.8) without taint
    checking at all?

    I am not interested in hearing that I do not want to do this.

    I understand I can get around variable taint checking with a do nothing
    sed-like replacement, but is it not clear to me how this could be done with
    the path.

    --
    Lars Eighner <http://larseighner.com/> <http://myspace.com/larseighner>
    Countdown: 560 days to go.
    Friends of Lizbeth: help replace failed a/c at Austin's no-kill shelter
    <https://secure.groundspring.org/dn/index.php?aid=12349>
     
    Lars Eighner, Jul 10, 2007
    #1
    1. Advertising

  2. Lars Eighner

    Paul Lalli Guest

    On Jul 10, 9:18 am, Lars Eighner <> wrote:
    > How can I turn off taint checking in a perl cgi script?


    By removing the -T option from the shebang in the script and/or the
    perl executable line in your webserver configuration file.

    I have now handed you a loaded hand gun and taught you how to point it
    at your head. Good luck.

    Paul Lalli
     
    Paul Lalli, Jul 10, 2007
    #2
    1. Advertising

  3. Lars Eighner

    -berlin.de Guest

    Lars Eighner <> wrote in comp.lang.perl.misc:
    > How can I turn off taint checking in a perl cgi script?
    >
    > I mean completely including path checking.
    >
    > Naturally I would like to do this on a per script basis, but if that
    > is not possible, is it possible to compile perl (5.8.8) without taint
    > checking at all?
    >
    > I am not interested in hearing that I do not want to do this.
    >
    > I understand I can get around variable taint checking with a do nothing
    > sed-like replacement, but is it not clear to me how this could be done with
    > the path.


    ( $_) = /(.*)/ for $ENV{ PATH};

    Anno
     
    -berlin.de, Jul 10, 2007
    #3
  4. Lars Eighner

    Paul Lalli Guest

    On Jul 10, 2:28 pm, Sherm Pendley <> wrote:
    > Lars Eighner <> writes:
    > > I understand I can get around variable taint checking with a do nothing
    > > sed-like replacement, but is it not clear to me how this could be done with
    > > the path.

    >
    > PATH is only used if you don't specify the location of the tool you're using -
    > if you use `ls` instead of `/bin/ls` for instance.


    Untrue.

    $ perl -Te'system("/bin/ls");'
    Insecure $ENV{PATH} while running with -T switch at -e line 1.

    Taint checking stops ANY external program from being run until $PATH
    is secured, because Perl takes the ultra-paranoid stance that /bin/ls
    might call some other program without specifying the full path, and
    then that program would be affected by the tainted $PATH.

    Paul Lalli
     
    Paul Lalli, Jul 10, 2007
    #4
  5. Paul Lalli wrote:
    > On Jul 10, 9:18 am, Lars Eighner <> wrote:
    >> How can I turn off taint checking in a perl cgi script?

    >
    > By removing the -T option from the shebang in the script and/or the
    > perl executable line in your webserver configuration file.


    I don't ever recall seeing anything like that in Apache.

    > I have now handed you a loaded hand gun and taught you how to point it
    > at your head. Good luck.



    It's amazing how it's always assumed that there isn't a valid reason for
    a question like this. The OP may have a perfectly good reason for doing
    what he's doing (like, say, debugging in some way), even if we don't
    know what it is. Granted, there's nothing wrong with reiterating a
    danger where danger potentially exists, but at the same time, it seems
    some people act too much like a "parental controls" mechanism, which
    only serves to take the focus from the original question itself.

    Give warning, by all means, but please try to address the question
    itself.

    AFAIK, if you are using setuid perl (where tainting is on by default,
    iirc), then a common method is using a c wrapper that's suid'ed to the
    desired user and executes the script, returning the output.

    --
    CL
     
    Clenna Lumina, Jul 11, 2007
    #5
  6. On 2007-07-11 07:57, Clenna Lumina <> wrote:
    > Paul Lalli wrote:
    >> On Jul 10, 9:18 am, Lars Eighner <> wrote:
    >>> How can I turn off taint checking in a perl cgi script?

    >>
    >> By removing the -T option from the shebang in the script and/or the
    >> perl executable line in your webserver configuration file.

    >
    > I don't ever recall seeing anything like that in Apache.


    Then your CGI scripts are probably not taint checked.

    AFAIK there are only two ways to turn taint checking on:

    1) Explicitely via the -T flag

    2) Implicitely by invoking the perl interpreter with a different ruid
    and euid.

    >> I have now handed you a loaded hand gun and taught you how to point it
    >> at your head. Good luck.

    [...]
    > Give warning, by all means, but please try to address the question
    > itself.


    He did, didn't he?


    > AFAIK, if you are using setuid perl (where tainting is on by default,
    > iirc), then a common method is using a c wrapper that's suid'ed to the
    > desired user and executes the script, returning the output.


    CGI scripts are generally not invoked with a different ruid and euid, so
    this is unlikely to be the reason. However, this can be checked with a
    simple script like

    #!/usr/bin/perl
    use warnings;
    use strict;
    print "Content-Type: text/plain\n";
    print "\n";
    print "ruid = $<\n";
    print "euid = $>\n";

    If this prints the same uid twice, -T flag is left as the only
    explanation.

    Another question to the OP: Are you really using CGI or are you using
    mod_perl? If you use the latter, you share one perl interpreter between
    scripts, so the either all have taint checking on or none of them.

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Jul 11, 2007
    #6
  7. Lars Eighner

    Lars Eighner Guest

    In our last episode, <>, the lovely and
    talented Clenna Lumina broadcast on comp.lang.perl.misc:

    > Paul Lalli wrote:
    >> On Jul 10, 9:18 am, Lars Eighner <> wrote:
    >>> How can I turn off taint checking in a perl cgi script?

    >>
    >> By removing the -T option from the shebang in the script and/or the
    >> perl executable line in your webserver configuration file.


    > I don't ever recall seeing anything like that in Apache.


    >> I have now handed you a loaded hand gun and taught you how to point it
    >> at your head. Good luck.



    > It's amazing how it's always assumed that there isn't a valid reason for
    > a question like this. The OP may have a perfectly good reason for doing
    > what he's doing


    Well, as a matter of fact I do. I am putting together tools to use
    to build static pages which are then uploaded to a server which is actually
    open to the public, unlike my local one. I've got one user. Me.

    > (like, say, debugging in some way), even if we don't
    > know what it is. Granted, there's nothing wrong with reiterating a
    > danger where danger potentially exists, but at the same time, it seems
    > some people act too much like a "parental controls" mechanism, which
    > only serves to take the focus from the original question itself.


    > Give warning, by all means, but please try to address the question
    > itself.


    > AFAIK, if you are using setuid perl (where tainting is on by default,
    > iirc), then a common method is using a c wrapper that's suid'ed to the
    > desired user and executes the script, returning the output.


    Well, apparently it is an apache problem -- or at least I have an
    apache problem. I cannot get suexec to work on 2.0.x; and nothing
    containing backticks, system, etc. works. Similar things also do not
    work in sh scripts (although of course everything runs fine from the
    commandline). Perl (when taint is given sneering lip service) and sh
    scripts work fine with apache 1.3.xx, but I don't have a php5 module that
    works with that. Likewise with versions of apache above 2.0.xx -- no
    php handler.

    Yes. I have compiled and installed five versions of apache in the last 24
    hours, and still cannot get a combination that will do both php5 and
    cgi, although each of them will do one or the other.


    Look folks, I'd like to sell you my new super secure Server-Scripting
    combination. It's called Rock v. 1.0. It is unhackable. It won't
    execute malicious code, because it won't execute any code at all.
    You can put it on your desk or collocate it -- like on the ground with other
    rocks. And you don't have to worry about your data, because it doesn't have
    any of your data. It's a Rock. And that seems to be what developers are
    trying to create.

    Hell, if I ran Windoz, it would be just as useless but at least I could
    watch the ripped-off videos on you tube.


    --
    Lars Eighner <http://larseighner.com/> <http://myspace.com/larseighner>
    Countdown: 559 days to go.
    Friends of Lizbeth: help replace failed a/c at Austin's no-kill shelter
    <https://secure.groundspring.org/dn/index.php?aid=12349>
     
    Lars Eighner, Jul 11, 2007
    #7
  8. Lars Eighner

    -berlin.de Guest

    Lars Eighner <> wrote in comp.lang.perl.misc:

    > Well, apparently it is an apache problem -- or at least I have an
    > apache problem. I cannot get suexec to work on 2.0.x; and nothing
    > containing backticks, system, etc. works. Similar things also do not
    > work in sh scripts (although of course everything runs fine from the
    > commandline). Perl (when taint is given sneering lip service) and sh
    > scripts work fine with apache 1.3.xx, but I don't have a php5 module that
    > works with that. Likewise with versions of apache above 2.0.xx -- no
    > php handler.


    Off topic, and at the risk of belaboring the obvious, have you checked
    $PATH in the different runs of apache?

    Anno
     
    -berlin.de, Jul 11, 2007
    #8
  9. -berlin.de wrote:
    > Lars Eighner <> wrote in comp.lang.perl.misc:
    >
    >> Well, apparently it is an apache problem -- or at least I have an
    >> apache problem. I cannot get suexec to work on 2.0.x; and nothing
    >> containing backticks, system, etc. works. Similar things also do not
    >> work in sh scripts (although of course everything runs fine from the
    >> commandline). Perl (when taint is given sneering lip service) and sh
    >> scripts work fine with apache 1.3.xx, but I don't have a php5 module
    >> that works with that. Likewise with versions of apache above 2.0.xx
    >> -- no php handler.

    >
    > Off topic, and at the risk of belaboring the obvious, have you checked
    > $PATH in the different runs of apache?


    Global symbol "$PATH" requires explicit package name at line 1.

    Maybe he should check $ENV{PATH} instead :)

    This will give you a nice list:

    print join("\n", split /:/, $ENV{PATH}), "\n";

    --
    CL
     
    Clenna Lumina, Jul 12, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Johann C. Rocholl

    Taint (like in Perl) as a Python module: taint.py

    Johann C. Rocholl, Feb 5, 2007, in forum: Python
    Replies:
    5
    Views:
    475
    Johann C. Rocholl
    Feb 6, 2007
  2. robert112
    Replies:
    1
    Views:
    443
    Juan T. Llibre
    Apr 26, 2007
  3. Louis Erickson
    Replies:
    2
    Views:
    213
    James Willmore
    Sep 3, 2003
  4. Ben
    Replies:
    17
    Views:
    236
  5. phill hw
    Replies:
    8
    Views:
    181
    phill hw
    Nov 18, 2004
Loading...

Share This Page