(ichimunki) Re: why is this tainted?

[ichimunki]

The error message doesn't say $email is tainted. $ENV{PATH} is. You must do something like $ENV{PATH} = '' to fix this, and then (as you are correctly doing) rely on providing the full path to your external applications in your script.

Also, $email, coming from an external source (the database) *should* be considered tainted (and once you fix the PATH variable, you may get a message for $email). It is tainted because it was not provided by your script, nor was it "cleaned" by your script. If someone can put a harmful string into your database, they've just fouled up your pipe. You will want to verify that $email is a conformant email address before sending it to sendmail.

All that said, I would strongly advise against using this sort of pipe to sendmail in a taint protected CGI. You might want to take a look at the various email modules on CPAN, especially Mail::Sendmail.

[michellem]

Thanks - that makes sense.

As to why I'm not using the Mail::Sendmail module (or others) is that this project is designed to be very portable, and work on systems where there may not be many modules installed. I can, of course include these modules in the source, but this system already depends on about 6 modules, and I'm trying not to have too many modules unless there are really compelling reasons. If I can handle things w/o a module fairly easily, I'm choosing that route.

[IlyaM]

For portable system I would not hard code path to sendmail binary. First of all most (I've seen) systems (several Linux distros and FreeBSD) use /usr/sbin/sendmail by default. Probably using SMTP would be more portable (it is quite safe to use Net::SMTP since libnet is popular enough to be installed on most systems).

But of course it is better to put such things in config.

--
Ilya Martynov (http://martynov.org/)

[ichimunki]

I understand your reasons, and they are commonly given as reasons why people are unwilling to use (certain) modules. But the modules don't necessarily have to be installed by the administrator and available site wide. They are often just Perl scripts themselves-- which means that you could potentially include them in your tarball as just another *.pm file. Or even easier for all involved: simply copy them right into your script in their own package space. (Again, assuming they are not dependent on being compiled and using a shared library or something).

But more importantly in the case of Mail::Sendmail... this module purports in its POD to *improve* portability by lessening the dependence on an actual sendmail executable. That right there is a compelling reason to give it a closer look, imho. Not to mention that whatever you are trying to do related to email has probably already been encoded there, which takes enormous weight off your shoulders.

Of course, unless you are likely to need email functionality every time this script loads, that may be overkill... but shell calls are vulnerable in lots of ways plain old Perl scripts aren't, which is a good reason to avoid them if at all possible, and where they must be done, why it is preferable to use established and tested interfaces, rather than rolling our own.

[belg4mit]

I see ichimunki has essentially said what follows, but let me just reiterate as this seems to be a FAQ.

Some of the mail sending modules will get you additional portability as they either implement their own SMTP server or rely upon a local or remote server. Mail::Sendmail is good for this, and some even have fallbacks down to a standard binary... (mailx, sendmail, etc.) You might also wish to consult this node.

--
perl -pe "s/\b;([st])/'\1/mg"