P4DTI issue job000396

TitleBugzilla 2.14 integration doesn't send notification e-mails
Assigned userGareth Rees
DescriptionIf you're running the P4DTI with Bugzilla 2.14, then notification e-mails aren't properly sent when a change is replicated from Perforce.
The following message appears in the standard error of the replicator:
Insecure $ENV{BASH_ENV} while running with -T switch at ./processmail line 745 (#1)
(F) You can't use system(), exec(), or a piped open in a setuid or setgid script if any of $ENV{PATH}, $ENV{IFS}, $ENV{CDPATH}, $ENV{ENV} or $ENV{BASH_ENV} are derived from data supplied (or potentially supplied) by the user. The script must set the path to a known value, using trustworthy data. See perlsec.
AnalysisThe processmail script has been changed in Bugzilla 2.14 so that it runs in Perl's "taint mode" (-T option to Perl). This is an execution mode that prevents you from invoking eval() or the shell with untrusted data. The offending line from the script is this one:
open(SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t")
This invokes the shell and so is vulnerable to untrausted settings for environment variaable PATH, BASH_ENV and so on.
This is a bug in the processmail script. In order to run in taint mode it should either (a) avoid invoking the shell at all, or (b) specify known values for the harmful environment variables. The reason that it works in normal use seems to be pure luck -- most web servers are running as some pseudo-user like "nobody" or "apache" who doesn't have a shell or an environment.
The processmail script should be changed so that it deletes the dangerous environment variables before invoking the shell, as recommended in the perlsec manpage. I submitted this to the Bugzilla developers as bug 101560 and the response suggests that a fix will be in 2.16.
In the mean time, we can include the fix in the Bugzilla 2.14 patch (it would have been nicer to work around the bug by deleting the offending environment variables before running processmail, but in fact there's no portable way to do so in Python -- del os.environ['BASH_ENV'] doesn't propagate to subshells. So we'd have to invoke processmail using os.execve(), which would make it harder to port the Bugzilla integration to Windows if we need to do that in the future.
GDR 2001-10-23: This is now fixed in Bugzilla [4]. The fix will presumably be in release 2.16.
How foundmanual_test
Evidence[1] <http://info.ravenbrook.com/mail/2001/09/21/17-16-58/0.txt>, item 2.3.
[2] <http://bugzilla.mozilla.org/show_bug.cgi?id=59349>
[3] <http://bugzilla.mozilla.org/show_bug.cgi?id=101560>
[4] <http://info.ravenbrook.com/mail/2001/10/23/15-52-02/0.txt>
Observed in1.1.6
Introduced in1.1.6
Created byGareth Rees
Created on2001-09-25 15:07:22
Last modified byGareth Rees
Last modified on2001-12-10 19:56:37
History2001-09-25 GDR Created.
2001-10-23 GDR Noted fix in Bugzilla.

Advice for all releases.

Symptoms: Using the Bugzilla integration, when someone changes a bug in Perforce, e-mail notifications aren't sent.

Cause: You haven't specified anything for the bugzilla_directory configuration parameter, or you've specified the wrong directory. The P4DTI can't find the processmail script which sends the e-mails.

Solution: Fix your setting for the bugzilla_directory configuration parameter.

Advice for release 1.2.0 or later

Cause: You're running Bugzilla 2.14 and you haven't applied the P4DTI patch, as described in section 5.4.1 of the P4DTI Administrator's Guide. You can check whether you've applied the patch by looking in globals.pl in your Bugzilla sources: if line 75 reads delete @ENV{qw(PATH IFS CDPATH ENV BASH_ENV)}; then you've applied the patch; if it reads delete $ENV{PATH}; then you haven't.

Solution: Apply the P4DTI patch to your Bugzilla 2.14 sources.


Change Effect Date User Description
22675 closed 2001-09-25 19:35:08 Gareth Rees Patched Bugzilla 2.14 to clear all the dangerous environment variables that taint mode might complain about, so that the P4DTI can run the processmail script.