Depending on your mail setup, you might want to simply skip that part that invokes the sendmail executable and use a direct SMTP connection:

return $mail->send('smtp');
[download]

In your code you don't show how you set $ENV{PATH} to a fixed value - I would start with that...

In your code you don't show how you set $ENV{PATH} to a fixed value - I would start with that...

That's because I don't!
Nowhere in my code have I set $ENV{PATH} so it is either part of the server configuration or it is set by another module. These are the ones I am using:

use DBI;
use DBD::mysql;
use Exporter;
use Template;
use MIME::Lite;
[download]

Update:
Printing $ENV{PATH} gives /usr/local/bin:/usr/bin:/bin

PATH_(variable), Env.

marto@Marto-Desktop:~$ echo $PATH
/home/marto/perl5/perlbrew/bin:/home/marto/perl5/perlbrew/perls/perl-5
+.32.1/bin:/home/marto/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/
+sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/
+marto/.local/bin:/home/marto/.local/bin:/snap/bin/openjdk/bin
marto@Marto-Desktop:~$ ./path.pl 
/home/marto/perl5/perlbrew/bin:/home/marto/perl5/perlbrew/perls/perl-5
+.32.1/bin:/home/marto/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/
+sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/
+marto/.local/bin:/home/marto/.local/bin:/snap/bin/openjdk/bin
marto@Marto-Desktop:~$ cat path.pl 
#!/usr/bin/perl
print "$ENV{PATH}\n";
[download]

In your code you don't show how you set $ENV{PATH} to a fixed value - I would start with that...

That's because I don't!

That means you haven't thoroughly read perlsec or Re: When not to use taint mode. (Yes, the latter contains a relevant update. It was added a few minutes after posting, three weeks ago.)

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Depending on your mail setup, you might want to simply skip that part that invokes the sendmail executable and use a direct SMTP connection

I think the underlaying send mechanism is SMTP. I only suspect this because I once sent quite a bit of mail through MIME::Lite and got an capacity error sent from the SMTP server. But I don't know for sure.

Setting MIME::Lite to use SMTP with $mime->send('smtp'); was still giving the same tainting error.

Since the problem is with MIME::Lite using $ENV{PATH}, if Corion's advice of switching to SMTP instead of sendmail doesn't work for you, I believe you should be able to untaint $ENV{PATH} before MIME::Lite uses it.

perlsec has a whole section on Cleaning Up Your Path

My experiments say yes. $ENV{PATH} = '/bin:/usr/bin:/usr/sbin'; delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; works for me to untaint the use of $ENV{PATH} before MIME::Lite tries to call sendmail. (That example assumes you trust /bin:/usr/bin:/usr/sbin, which I cannot decide for you.) To be on a system that has sendmail, I had to use perl v5.8.5, which isn't exactly cutting edge, so things may have changed since then... but in my experiments, I could untaint the PATH before MIME::Lite uses it.

Thank you - that explains exactly where the problem is...

Would this be a sensible way to untaint $ENV{'PATH'} without losing the portability of the code and without introducing huge security risks?

my $path = $ENV{'PATH'};
$ENV{'PATH'} = undef;
foreach my $p(split /:/, $path) {
    if ($p =~ m!^(/(usr|bin).*)!) {
        $ENV{'PATH'} .= ':' if $ENV{'PATH'};
        $ENV{'PATH'} .= $1;
    }
}
[download]

sensible way to untaint $ENV{'PATH'} without losing the portability

Just set $ENV{'PATH'} to /bin:/usr/bin. That's what you get by default when nothing else is set (default set in init, libc, and some other places), and that's where all important binaries can be found. If you need "exotic programs" that are not in /bin or /usr/bin, put their path into the configuration file.

my $path = $ENV{'PATH'};
$ENV{'PATH'} = undef;
foreach my $p(split /:/, $path) {
    if ($p =~ m!^(/(usr|bin).*)!) {
        $ENV{'PATH'} .= ':' if $ENV{'PATH'};
        $ENV{'PATH'} .= $1;
    }
}
[download]

That looks broken.

You add every element of PATH to the new PATH if it starts with /usr or /bin. Including /usr/u0/evil.me (that's how HOME once looked like, before /home became common), /binary/garbage, /usr.corrupted, /usr/sbin, /usr/svr4/bin, /usr/etc, and so on.

Also, why don't you use join to combine the "cleaned" elements?

Just don't. The predefined PATH is unreliable, that's why perl considers it tainted. Set a sane default, don't try to repair the mess found in PATH. It just makes things worse. /bin:/usr/bin is sane.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Your example code assumes that the entirety of /usr and /bin are inherently safe. I cannot answer for you whether that is true on your webserver (which, IIRC, is a shared hosting server). edit:in light of afoken's additional points, I concur that your snippet was not sufficient./edit

Further, your example code ignores the remainder of the untainting in my example snippet, and shows that you didn't read the whole of perlsec, nor even the few paragraphs in the section called Cleaning Up Your Path. The delete was there for a reason; that reason was explained in the documentation I linked, but can be summed up in the statement that those other environment variables can affect execution similar to PATH. If you do not follow the complete advice, perl will still consider $ENV{PATH} tainted until you take care of those other environment variables as well.

But if you believe the assumptions about those paths is valid, and if you have implemented but not shown the other advice mentioned, then your code seems a reasonable way of making sure that only the "safe" path elements are included. edit:struck out; see afoken's additional points for why your code still isn't a reasonable way to trim the PATH/edit

But, while cleaning up PATH (and the related variables) is advisable from an un-tainting perspective, I think that Corion's advice in Re: Insecure CPAN module in taint mode is still even better: why fork out to an external process unless necessary?

edit:see inline edits/edit

G'day Bod,

I didn't see it mentioned anywhere in the thread, so I thought I'd point out a general problem that you could be experiencing.

Here's a taint_test module:

$ cat taint_test.pm
package taint_test;

use strict;
use warnings;

chdir +(split /:/, $ENV{PATH})[0];
[download]

Here's a script that tries to clean $ENV{PATH}:

$ cat check_taint_1.pl
use strict;
use warnings;

$ENV{PATH} = '/bin:/usr/bin';
use lib '.';
use taint_test;
[download]

But that fails:

$ perl -T check_taint_1.pl
Insecure dependency in chdir while running with -T switch at taint_tes
+t.pm line 6.
Compilation failed in require at check_taint_1.pl line 6.
BEGIN failed--compilation aborted at check_taint_1.pl line 6.
$
[download]

The problem here is that the assignment to $ENV{PATH} occurs at runtime, whereas loading taint_test occurs at compile time. The order of the statements makes no difference: compile time happens before runtime.

Here's a subtly different version of the first script:

$ cat check_taint_2.pl
use strict;
use warnings;

BEGIN { $ENV{PATH} = '/bin:/usr/bin'; }
use lib '.';
use taint_test;
[download]

And this one works:

$ perl -T check_taint_2.pl
$
[download]

Both assignment and loading occur at compile time; the order of the statements now matters.

Here's a third version of the script with the order of statements changed:

$ cat check_taint_3.pl
use strict;
use warnings;

use lib '.';
use taint_test;
BEGIN { $ENV{PATH} = '/bin:/usr/bin'; }
[download]

And, as expected, this fails:

$ perl -T check_taint_3.pl
Insecure dependency in chdir while running with -T switch at taint_tes
+t.pm line 6.
Compilation failed in require at check_taint_3.pl line 5.
BEGIN failed--compilation aborted at check_taint_3.pl line 5.
$
[download]

Bear this in mind for things other than untainting $ENV{PATH}.