On Wed, Feb 16, 2022 at 02:15:31PM -0500, Wietse Venema wrote:
> > Well, if a message contains non-printable characters in the sender,
> > one of the recipient addresses, or delay reason, and I process the
> > output of "postqueue -j" in a language that supports JSON ("jq",
> > "python", "perl", ...) then it should be possible to see the actual
> > data without sanitisation.
>
> Then we can ad a -R option that disables filtering (make then do
> something extra) with a warning. Will this be necessary for Postfix
> 3.7? Probably, so that we don't have too much difference between
> examples of how to do things.
Sure, it would be a reasonably small backwards-compatible addition.
> The threat model is that an attacker can compromise a process with
> user "postfix" privileges and subvert the showq daemon or the content
> of queue files. The showq daemon is supposed to ignore bogus queue
> IDs, bogus queue names, and non-files.
Right, it is important to stress in documentation and exampels of the
use of such a feature that "postqueue -J" or be it "postqueue -R -j"
output is *untrusted* (tainted) and use of the data by e.g. "root" needs
to exercise caution.
> Or, that some well-meaning moron changes Postfix to preserve newlines
> in, for example, responses from remote SMTP servers.
Are we sure that presently, even without sanitisation there are no
valid cases in which the output of "postqueue -j" would contain
strings with non-printable content?
Can Postfix accept (without mangling) (with <ESC> representing
the underlying character) any of:
Server:
MAIL FROM:<"foo+\<ESC>bar"@example.com>
RCPT TO:<"foo+\<ESC>bar"@example.com>
Client:
450 4.0.0 You won't <ESC> our filters
[ IIRC multi-line responses get merged into a single line in the SMTP
client, but I'm not sure, and haven't checked just now. ]
> Either way, that would subvert text-based postqueue|whatever|postsuper
> pipelines that typically run as root.
Yes. Unsanitised untrusted input and root mix poorly.
--
Viktor.
