From: Jani Nikula <jani@nikula.org>
To: J Farkas <jf.hyqohaczlksw4tx6ae@l2015aftruuq.dns007.net>,
 notmuch@notmuchmail.org
Cc: Tomi Ollila <tomi.ollila@iki.fi>
Subject: Re: cli/insert: do not lose the SMTP envelope
In-Reply-To: <1451735416.13.504ebc4c@201601.l2015aftruuq.dns007.net>
References: <1451647279.42.86b0a8ab@201601.l2015aftruuq.dns007.net>
 <m2a8oob4ql.fsf@guru.guru-group.fi>
 <1451735416.13.504ebc4c@201601.l2015aftruuq.dns007.net>
User-Agent: Notmuch/0.21+34~ge1fb729 (http://notmuchmail.org) Emacs/24.4.1
 (x86_64-pc-linux-gnu)
Date: Sun, 03 Jan 2016 18:15:05 +0200
Message-ID: <877fjqwsfq.fsf@nikula.org>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Sat, 02 Jan 2016, J Farkas <jf.hyqohaczlksw4tx6ae@l2015aftruuq.dns007.net> wrote:
> On 2016-01-02 at 13:28:02, Tomi Ollila wrote:
>> On Fri, Jan 01 2016, J Farkas <jf.hyqohaczlksw4tx6ae@l2015aftruuq.dns007.net> wrote:
>> > Make sure we store the envelope sender/recipient if provided by
>> > qmail-command(8) in $RPLINE and $DTLINE.
>> > ---
>> 
>> Probably good feature, but like
>> http://www.qmail.org/man/man8/qmail-command.html 
>> says:
>> 
>>           qmail-local supplies several useful environment variables to
>>           command.  WARNING: These environment variables are not
>>           quoted.  They may contain special characters.  They are
>>           under the control of a possibly malicious remote user.
>> 
>> Should we check that the contents of RPLINE and DTLINE are well-formed
>> before writing these to the mail files ?
>
> Thank you for reviewing and being so careful!
>
> That warning is not applicable for the *LINE variables which are
> supposed to end up in the message without further munging (they even
> have the LF appended already).
>
> The extra carefulness is only relevant for anyone trying to *parse*
> those strings, like $EXT via unsafe languages, when EXT becomes the
> part following the dash after the username (considering 
> bgates-(){:;};shutdown@example.org for example)

We should already assume that the messages can contain basically any
malicious content, and we should treat them like that. Adding malicious
content at this step should not trip us over.

The question is, could this make it easier for Mallory to inject
malicious content to otherwise good messages? The environment variables
in question could contain a whole message, hiding the actual
message. Not sure how one could control the environment without being
able to do a whole lot of other, potentially more malicious things.

BR,
Jani.


>
> It still should be what the envelope sender was, and what was considered
> valid at the time.
>
> I actually checked if there's any relevance for this warning: most
> maildir delivering program does it already in one form or the other; in
> fact, there is a command in the qmail distribution:
> http://www.qmail.org/man/man1/preline.html which does the exact same
> getenv and copy to the output.
>
> If you'd liek to confirm, there's one repo for what seems to be the
> original qmail source for this file shows even DJB does it the same way:
>
> https://github.com/c-rack/qmail/blob/master/preline.c
>
> I would think it's not worth the extra fork and pipe for this.  I don't
> see how anyone could do without these headers saved, to be honest :)
>
> Janos
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch