Lines containing a single dot "." are indicating the end of the message. The remaining part of the message could be arbitrarily executed by the SMTP server. <justdave> I'd venture to call that a security bug <justdave> because you can embed SMTP commands in an email and make it do weird things <LpSolit> wicked, justdave: where is going the remaining part of the email? <wicked> LpSolit: to the SMTP server for execution if justdave is right <justdave> LpSolit: depends on the transport mechanism, which is controlled by Mail::Mailer (which is why it's Mail::Mailer's bug and not ours) <justdave> if the transport is SMTP, it'd be going into the SMTP stream <justdave> iow, interpreted as commands since the . terminates the DATA phase <LpSolit> justdave: what nasty things could be done? something dangerous? <justdave> send mail to arbitrary people and make it look like it came from Bugzilla's server . THIS PART OF THE COMMENT HAS NOT BEEN SENT!!! (ARBITRARY CODE HERE)
OK, upon further investigation, Mail::Mailer does indeed do the correct thing with SMTP mail_delivery_method, escaping the period so it goes through. However, it's failing to set -i on the command line when it calls sendmail, so the sendmail method is truncating the comments at the period. This makes it no longer a security bug, but the severity can stay, because it's still dataloss. Just to make it clear, this is a bug in Mail::Mailer, not in Bugzilla. Does someone know where to submit bugs for that? The patch to fix should be easy, just add -i to the command line for sendmail.
There is a mechanism that lets you add arbitrary arguments to the senamil call... push @args, '-firstname.lastname@example.org'; for example...
Mail::Mailer is maintained by Mark Overmeer <email@example.com>. Probably the best thing to do would be to email him with a bug report.
BTW, resolution of this bug as far as Bugzilla is concerned is bumping the minimum required version of Mail::Mailer to the next release including a fix for this. 2.20 is already out with this, so we shouldn't block a release waiting for it. We can backport the additional requirement to the branches once the fixed version is available though. We should relnote it regardless.
(In reply to comment #3) > Mail::Mailer is maintained by Mark Overmeer <firstname.lastname@example.org>. Probably > the best thing to do would be to email him with a bug report. Who volounteers to send him an email? justdave, zach?
Created attachment 204968 [details] [diff] [review] patch, v1 This fixes the problem on landfill...
I believe that glob is our Mail::Mailer expert. Any replies to comment 1? :-)
(In reply to comment #7) > I believe that glob is our Mail::Mailer expert. Any replies to comment 1? :-) mark was responsive when i emailed him regarding the issues i found when doing the utf-8 patch.
I still think Mail::Mailer should be insulating us from this, but this is definitely a good workaround for it (and because of how Mail::Mailer does work, this probably won't break once it's fixed, and it lets us support older versions of Mail::Mailer still).
tip: Checking in Bugzilla/BugMail.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/BugMail.pm,v <-- BugMail.pm new revision: 1.57; previous revision: 1.56 done 2.20: Checking in Bugzilla/BugMail.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/BugMail.pm,v <-- BugMail.pm new revision: 220.127.116.11; previous revision: 18.104.22.168 done
*** Bug 333774 has been marked as a duplicate of this bug. ***
*** Bug 350972 has been marked as a duplicate of this bug. ***