misterperl has asked for the wisdom of the Perl Monks concerning the following question:

I'm studying perlsec and taint mode, trying to shore up our security. This statement seems misleading:

By default, Perl automatically enables a set of special security checks, called taint mode, when it detects its program running with differing real effective user or group IDs. You can also enable taint mode explicitly by using the -T command line flag.

In our case, CGI runs under the apache user, but the file owner is different, so by that statement I'd expect we'd run with taint mode by dafault. There seems to be no way to DISABLE taint mode, so its not really a "default" since default means that TAINT MODE can be disabled. I don't see a switch that disables TAINT mode.

But when I explicitly enable that pragma, the code immediately blows up with security errors, implying the default run mode is NOT taint-pragmatized.

Digging a bit deeper, the on-screen error was like:

Software error: Insecure dependency in require while running with -T switch at /var/ww +w/cgi-bin/mycode/generic.cgi line 47. <code><p> and like 47 was like: <p><code> use myPackage;

which is a package of 1000's of lines. It seems odd taint complains about some "require" issue when it actually "use". And the package has no "requires" in it either. So an error like this is about as useful as telling the coastguard "there is a ship in some sort of distress, SOMEWHERE in the ocean!"..

Honestly, I believe the RIGHT thing to do is to run with TAINT mode. But in practice, with messages like this with no way to tell what to fix, its not useful. I'd be very interested in video journals or other guides that show how users remediate TAINT issues like these and others? Or is there a means to make taint mode VERBOSE?

Replies are listed 'Best First'.
Re: Perlsec and taint mode?
by haj (Vicar) on Oct 27, 2023 at 15:30 UTC
    In our case, CGI runs under the apache user, but the file owner is different, so by that statement I'd expect we'd run with taint mode by dafault.

    This is a misunderstanding. File ownership has nothing to do with that situation. This mandatory activation of taint mode happens as a consequence of a setuid (or setgid operation: Changing the user id of a process.

    So an error like this is about as useful as telling the coastguard "there is a ship in some sort of distress, SOMEWHERE in the ocean!"..

    It more precise than that. require is the first step of a use operation, and it is the most likely culprit. I guess that somewhere in your effective @INC path you have a directory which is considered insecure by taint checks. This can be as simple as a relative directory, because in most cases the return value of cwd (i.e. determining the current working directory) is tainted.

Re: Perlsec and taint mode?
by ikegami (Patriarch) on Oct 27, 2023 at 16:54 UTC

    Files don't have real and effective uids and gids. Processes do. Taint is enabled when a process's real and effective uids are different, and when its real and effective gids are different.

    To get the necessary criteria in your scenario, the file would have needed to have its setgid flag set, or Apache would have needed to use setuid in the spawned process. Or the equivalent for gid.

Re: Perlsec and taint mode?
by Corion (Patriarch) on Oct 27, 2023 at 15:32 UTC

    The problem likely means that @INC was not taint-cleaned when your program started up.