[exim] Inconsistent detection of tainted command in ${run} 4.96
Hi mailing list,
We have an external tool for checking user authentication, but running
it seems to be labelled as tainted inconsistently after upgrading to
4.96.
Here is our PLAIN auth:
plain:
driver = plaintext
public_name = PLAIN
server_prompts = :
server_condition = ${run,preexpand{/usr/bin/eximpassword
"--localpart=${local_part:$2}" "--hostname=${domain:$2}"
"--password=${rxquote:$3}"}{yes}{no}}
server_set_id = $2
server_advertise_condition = ${if eq{$tls_in_cipher}{}{}{*}}
This results in a failure to run as apparently the path is tainted even
though it is hard coded:
722716 plain authenticator server_condition:
722716 $auth1 =
722716 $auth2 = u...@example.com
722716 $auth3 = Password!
722716 $1 =
722716 $2 = u...@example.com
722716 $3 = Password!
722716 direct command:
722716 argv[0] = '/usr/bin/eximpassword'
722716 argv[1] = '--localpart=user'
722716 argv[2] = '--hostname=example.com'
722716 argv[3] = '--password=Password!'
722716 LOG: MAIN PANIC
722716 Attempt to exec tainted path: '/usr/bin/eximpassword'
722716 expansion failed: couldn't create child process: Operation not
permitted
However, and here's where things get confusing, here is our LOGIN auth
where we run an **identical** command:
login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = ${run,preexpand{/usr/bin/eximpassword
"--localpart=${local_part:$1}" "--hostname=${domain:$1}"
"--password=${rxquote:$2}"}{yes}{no}}
server_set_id = $1
server_advertise_condition = ${if eq{$tls_in_cipher}{}{}{*}}
This works, as if untainted:
723062 login authenticator server_condition:
723062 $auth1 = u...@example.com
723062 $auth2 = Password!
723062 $1 = u...@example.com
723062 $2 = Password!
723062 direct command:
723062 argv[0] = '/usr/bin/eximpassword'
723062 argv[1] = '--localpart=user'
723062 argv[2] = '--hostname=example.com'
723062 argv[3] = '--password=Password!'
723062 daemon-accept forking for expand-run
723062 daemon-accept forked for expand-run: 723068
723068 postfork: expand-run
723062 expanded string: yes
723062 SMTP>> 235 Authentication succeeded
The documentation on
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html#SECID82
doesn't seem to cover how ${run} is checked for taint during expansion.
Why are seemingly identical commands inconsistently marked as tainted? Is
this a bug please? If it's by design is there any more documentation
about how ${run} is expanded please?
Thanks in advance,
--
Andrew.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Inconsistent detection of tainted command in ${run} 4.96
Hi mailing list,
We have an external tool for checking user authentication, but running
it seems to be labelled as tainted inconsistently after upgrading to
4.96.
Here is our PLAIN auth:
plain:
driver = plaintext
public_name = PLAIN
server_prompts = :
server_condition = ${run,preexpand{/usr/bin/eximpassword
"--localpart=${local_part:$2}" "--hostname=${domain:$2}"
"--password=${rxquote:$3}"}{yes}{no}}
server_set_id = $2
server_advertise_condition = ${if eq{$tls_in_cipher}{}{}{*}}
This results in a failure to run as apparently the path is tainted even
though it is hard coded:
722716 plain authenticator server_condition:
722716 $auth1 =
722716 $auth2 = u...@example.com
722716 $auth3 = Password!
722716 $1 =
722716 $2 = u...@example.com
722716 $3 = Password!
722716 direct command:
722716 argv[0] = '/usr/bin/eximpassword'
722716 argv[1] = '--localpart=user'
722716 argv[2] = '--hostname=example.com'
722716 argv[3] = '--password=Password!'
722716 LOG: MAIN PANIC
722716 Attempt to exec tainted path: '/usr/bin/eximpassword'
722716 expansion failed: couldn't create child process: Operation not
permitted
However, and here's where things get confusing, here is our LOGIN auth
where we run an *identical* command:
login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = ${run,preexpand{/usr/bin/eximpassword
"--localpart=${local_part:$1}" "--hostname=${domain:$1}"
"--password=${rxquote:$2}"}{yes}{no}}
server_set_id = $1
server_advertise_condition = ${if eq{$tls_in_cipher}{}{}{*}}
This works, as if untainted:
723062 login authenticator server_condition:
723062 $auth1 = u...@example.com
723062 $auth2 = Password!
723062 $1 = u...@example.com
723062 $2 = Password!
723062 direct command:
723062 argv[0] = '/usr/bin/eximpassword'
723062 argv[1] = '--localpart=user'
723062 argv[2] = '--hostname=example.com'
723062 argv[3] = '--password=Password!'
723062 daemon-accept forking for expand-run
723062 daemon-accept forked for expand-run: 723068
723068 postfork: expand-run
723062 expanded string: yes
723062 SMTP>> 235 Authentication succeeded
The documentation on
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html#SECID82
doesn't seem to cover how ${run} is checked for taint during expansion.
Why are seemingly identical commands inconsistently marked as tainted?
Is this a bug please? If it's by design is there any more documentation
about how ${run} is expanded please?
Thanks in advance,
--
Andrew.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: Inconsistent detection of tainted command in ${run} 4.96
On 01/09/2023 08:48, Andrew Hearn via Exim-users wrote:
If it's by design is there any more documentation
about how ${run} is expanded please?
The docs I'm looking at,
https://exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html
say, for ${run...} :-
"If the option preexpand is used
[...]
Neither the command nor any argument may be tainted."
So, in your PLAIN authenticator you had used attacker-supplied data
($1) in the command args; with the preexpand option which requests the
entire command+args expanded as one string. The taint from $1 taints
the expanded string. That string is only then split for the argv
(executable path and arguments), and every element resulting is tainted.
You could track this getting done by using the "expand" debug channel
(probably there already, but you didn't show it to us).
What docs were you looking at?
Regarding your LOGIN authentication not behaving the same way, this
smells like a bug: failing to track taint in the more-complex
sequence that the LOGIN method uses. I'll look into this; thanks
for pointing it up.
--
Cheers,
Jeremy
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: Inconsistent detection of tainted command in ${run} 4.96
On Fri, 1 Sept 2023 at 10:50, Andrew Hearn via Exim-users
wrote:
>
> Hi mailing list,
>
> We have an external tool for checking user authentication, but running
> it seems to be labelled as tainted inconsistently after upgrading to
> 4.96.
>
> Here is our PLAIN auth:
>
> plain:
>driver = plaintext
>public_name = PLAIN
>server_prompts = :
>server_condition = ${run,preexpand{/usr/bin/eximpassword
> "--localpart=${local_part:$2}" "--hostname=${domain:$2}"
> "--password=${rxquote:$3}"}{yes}{no}}
>server_set_id = $2
>server_advertise_condition = ${if eq{$tls_in_cipher}{}{}{*}}
>
> This results in a failure to run as apparently the path is tainted even
> though it is hard coded:
>
> 722716 plain authenticator server_condition:
> 722716 $auth1 =
> 722716 $auth2 = u...@example.com
> 722716 $auth3 = Password!
> 722716 $1 =
> 722716 $2 = u...@example.com
> 722716 $3 = Password!
> 722716 direct command:
> 722716 argv[0] = '/usr/bin/eximpassword'
> 722716 argv[1] = '--localpart=user'
> 722716 argv[2] = '--hostname=example.com'
> 722716 argv[3] = '--password=Password!'
> 722716 LOG: MAIN PANIC
> 722716 Attempt to exec tainted path: '/usr/bin/eximpassword'
> 722716 expansion failed: couldn't create child process: Operation not
> permitted
>
> However, and here's where things get confusing, here is our LOGIN auth
> where we run an **identical** command:
>
> login:
>driver = plaintext
>public_name = LOGIN
>server_prompts = "Username:: : Password::"
>server_condition = ${run,preexpand{/usr/bin/eximpassword
> "--localpart=${local_part:$1}" "--hostname=${domain:$1}"
> "--password=${rxquote:$2}"}{yes}{no}}
>server_set_id = $1
>server_advertise_condition = ${if eq{$tls_in_cipher}{}{}{*}}
>
> This works, as if untainted:
>
> 723062 login authenticator server_condition:
> 723062 $auth1 = u...@example.com
> 723062 $auth2 = Password!
> 723062 $1 = u...@example.com
> 723062 $2 = Password!
> 723062 direct command:
> 723062 argv[0] = '/usr/bin/eximpassword'
> 723062 argv[1] = '--localpart=user'
> 723062 argv[2] = '--hostname=example.com'
> 723062 argv[3] = '--password=Password!'
> 723062 daemon-accept forking for expand-run
> 723062 daemon-accept forked for expand-run: 723068
> 723068 postfork: expand-run
> 723062 expanded string: yes
> 723062 SMTP>> 235 Authentication succeeded
>
> The documentation on
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html#SECID82
> doesn't seem to cover how ${run} is checked for taint during expansion.
>
> Why are seemingly identical commands inconsistently marked as tainted? Is
> this a bug please? If it's by design is there any more documentation
> about how ${run} is expanded please?
>
> Thanks in advance,
Hello. I just recently upgraded to 4.96 and was hit with similar issues.
You need to get rid of the user set variables by doing lookups. I'm
not sure where you look them up elsewhere but well, I had:
server_condition = "${if
crypteq{$auth3}{${extract{1}{:}{${lookup{${local_part:$auth2}}lsearch{CONFDIR/domains/{domain:$auth2}/passwd}{$value}{*:*}{1}{0}}"
and Exim complained about the {domain:$auth2} so I had to replace it with:
server_condition = "${if
crypteq{$auth3}{${extract{1}{:}{${lookup{${local_part:$auth2}}lsearch{CONFDIR/domains/${lookup{${domain:$auth2}}dsearch{CONFDIR/domains}}/passwd}{$value}{*:*}{1}{0}}"
where I have directories for each domain under CONFDIR/domains, that
I'm matching the {domain:$auth2} against; if nothing's found the
lookup returns an empty string. This protects against injection
attacks.
Hope this sets you on the right path.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] No immediate delivery for emails locally submitted in systemd unit
Hello, I have a very strange behaviour on my exim servers (debian 11, version 4.94.2). I have systemd timers and units which send email in case of error. When email is submitted this way, it is placed on the exim queue without being immediately delivered and waits the next queue run as specifed with the -q option (default 30 min). When I run the same submit command from a shell, the mail is delivered immediately as expected. The systemd unit configuration is the following : ExecStopPost=-/bin/bash -c 'if [ "$EXIT_STATUS" != "0" ]; then mail -s "ERROR executing arch-build" "$MAILTO" <<<"SYSTEMD status \n Service_result: $SERVICE_RESULT \n Exit_code(systemd): $EXIT_CODE \n Exit_status(proc exit code): $EXIT_STATUS\n`journalctl --no-pager -n 100 -u arch-build.service`"; fi' When the unit stops, this option runs a shell script which checks the service status and submits mail with a simple 'mail' command when failed. Email is placed in the queue waiting as the exim logs show: 2023-08-24 11:38:32 1qZCTf-00A5Gx-Ns <= root@*.edibox.ca U=root P=local S=9329 2023-08-24 11:43:12 Start queue run: pid=2403642 2023-08-24 11:43:13 1qZCTf-00A5Gx-Ns => charles.lecl...@edibox.ca R=smarthost T=remote_smtp_smarthost H=*.edibox.ca [172.25.1.2] K C="250- 9017 byte chunk, total 9445\\n250 OK id=1qZCUL-0049vY-2h" 2023-08-24 11:43:13 1qZCTf-00A5Gx-Ns Completed 2023-08-24 11:43:13 End queue run: pid=2403642 When using the very same 'mail' command from a remote shell (or from a shell script), the logs are : 2023-08-24 12:50:34 1qZDXW-00A7Y6-H1 <= root@*.edibox.ca U=root P=local S=417 2023-08-24 12:50:35 1qZDXW-00A7Y6-H1 => charles.lecl...@edibox.ca R=smarthost T=remote_smtp_smarthost H=*.corp.edibox.ca [172.25.1.2] K C="250- 432 byte chunk, total 432\\n250 OK id=1qZDXW-004EGB-Sp" 2023-08-24 12:50:35 1qZDXW-00A7Y6-H1 Completed I've tried looking in the configuration but didn't find anything. Why would delivering of identical, locally submitted emails, differ ? Thanks for your answers, Charles Leclerc Edibox Inc. -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: No immediate delivery for emails locally submitted in systemd unit
Ahoj, Dňa Thu, 24 Aug 2023 19:46:50 +0200 Charles Leclerc via Exim-users napísal: > I've tried looking in the configuration but didn't find anything. Why > would delivering of identical, locally submitted emails, differ ? I will guess only, but exim is forking transport process for delivery, but that is not liked by systemd (in really i read from its author, that he consider forking as bad). By that, systemd kill all remaining processes after/when unit stops (and do not wait for forked processes) by default. You have several options: + use forking type unit (not appropriate in all cases) + disable kill in unit (not very good idea) + setup sendwait in mailx (not with bsd-mailx) + use exim directly with -odf + use cron for repeated tasks For timers (repeated tasks) requiring mails i usually use cron (as i use bsd-mailx, without sendwait suport). While systemd has a lot of useful features (as init system), the lack of simple notification in it is its big minus. regards -- Slavko https://www.slavino.sk pgpM4cLKqMzu0.pgp Description: Digit??lny podpis OpenPGP -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: No immediate delivery for emails locally submitted in systemd unit
On 2023-09-01 Slavko via Exim-users wrote: [...] > You have several options: > + use forking type unit (not appropriate in all cases) > + disable kill in unit (not very good idea) > + setup sendwait in mailx (not with bsd-mailx) > + use exim directly with -odf > + use cron for repeated tasks + Inject the messages via SMTP, e.g. with swaks. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Re: No immediate delivery for emails locally submitted in systemd unit
On 2023-09-01, Andreas Metzler via Exim-users wrote: > On 2023-09-01 Slavko via Exim-users wrote: > [...] >> You have several options: > >> + use forking type unit (not appropriate in all cases) >> + disable kill in unit (not very good idea) >> + setup sendwait in mailx (not with bsd-mailx) >> + use exim directly with -odf >> + use cron for repeated tasks > > + Inject the messages via SMTP, e.g. with swaks. yes, or "nullmailer" which is a /usr/bin/sendmail replacement. you might have to install from source as the debian nullmailer package conflicts with exim (because the both provide sendmail) -- Jasen. 🇺🇦 Слава Україні -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
