Re: [exim] Sieve filters broken due to tainted expansions?
First, I don't need duplicate copies of mails. I read the list. A copy direct to me is wasting my time. On 15/01/2020 21:35, Chris Siebenmann via Exim-users wrote: > Is there a way of un-tainting things from $local_part? At the time you are validating local_part, obtain a value from a trusted place (eg. the DB that you are using for that validation). -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
> > What's the suggested way to do that for virtual domains, that is many
> > mailboxes that all belong to the same local user, and which are not
> > obtained through a lookup, but through the filesystem itself?
>
> The result of a lookup is untainted, and will likely remain so
> (even if the key for the lookup is tainted, eg. $local_part).
> So whatever you're doing now should still work, so long as you
> don't name the DB for the lookup using tainted data.
Is there a way of un-tainting things from $local_part? We have a
long-standing little feature where we implement per-address settings
for things like blocklists using databases read from directories named
after the local addresses, more or less:
UBDIR = CFDIR/${lc:$local_part}
deny
domains = +local_domains
senders = ${if exists {UBDIR/senders} {UBDIR/senders}}
message = mail from ...
We have not yet updated to a version of Exim that uses tainting and so
I don't know if this usage will be immediately affected, but it seems
that this is now being considered questionable in at least this form.
(We already check and sanitize $local_part, so this is safe in our
usage. People do not get to create valid local addresses with eg '/../'
in them, and if they did manage it somehow, explicit address content
checks would reject them earlier. Also, these per-user files must be
updated by root, so we consider their contents safe.)
- cks
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On 09/01/2020 23:34, Jeremy Harris via Exim-users wrote: > That's a stage of enforcement yet to be implemented. Perhaps next > release. Implemented by the series leading up to 9e21ce8fc4. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On 09/01/2020 19:52, Michael Haardt via Exim-users wrote: >> ChangeLog, 4.93 :- >> >> JH/32 >> Introduce a general tainting mechanism for values read from the input >>channel, and values derived from them. Refuse to expand any tainted >> values, to catch one form of exploit. > > Ok, so the problem was not in Sieve operation itself, but in the fact that > a Sieve script was read (expanded) from a path that contained $local_part? > If so, why was the script executed? That's a stage of enforcement yet to be implemented. Perhaps next release. Currently, only explicit expansions have the enforcmeent but it needs extending to implicit ones also. > What's the suggested way to do that for virtual domains, that is many > mailboxes that all belong to the same local user, and which are not > obtained through a lookup, but through the filesystem itself? The result of a lookup is untainted, and will likely remain so (even if the key for the lookup is tainted, eg. $local_part). So whatever you're doing now should still work, so long as you don't name the DB for the lookup using tainted data. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
> ChangeLog, 4.93 :- > > JH/32 > Introduce a general tainting mechanism for values read from the input >channel, and values derived from them. Refuse to expand any tainted > values, to catch one form of exploit. Ok, so the problem was not in Sieve operation itself, but in the fact that a Sieve script was read (expanded) from a path that contained $local_part? If so, why was the script executed? What's the suggested way to do that for virtual domains, that is many mailboxes that all belong to the same local user, and which are not obtained through a lookup, but through the filesystem itself? Michael -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On 07/01/2020 20:20, Michael Haardt via Exim-users wrote: > I did > not really follow the list recently, so I missed the introduction of > "tainted" expansions, To follow up on that point: ChangeLog, 4.93 :- JH/32 Introduce a general tainting mechanism for values read from the input channel, and values derived from them. Refuse to expand any tainted values, to catch one form of exploit. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On 08/01/2020 12:59, Jeremy Harris via Exim-users wrote: > I'll be trying to invent some verbiage for bits of the docs to > guide people away from using $local_part directly... Some words committed as cf8b2c5789, should anyone have further suggestions. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On Wed, 8 Jan 2020, Tobias Klausmann via Exim-users wrote: Hi! On Wed, 08 Jan 2020, Andrew C Aitchison wrote: On Wed, 8 Jan 2020, Tobias Klausmann via Exim-users wrote: user=$local_part verify=false transport = local_delivery If you have check_local_user you shouldn't need user=$local_part as well. Ah, good point, thanks. And this seems to work. I'll test it for a bit and report back. Is the use of $local_part in the transports seen as safe, or should I cange those to use $home as well? On principle I would say change them too. If $home and /home/$local_part are different directories which do you want ? The one from the password file/database or the one derived from the potential hacker's input ? If /home fills up and you put a new user on a different disk/partition/volume $home will still work, but /home/$local_part would need attention ... Yeah, you're right. I presume I need no extra steps for $home being defined in the context of the transports? Not sure. spec.txt has a transport "procmail_pipe:" which has user = $local_part and configure.default does not have check_local_user on any transports. Best wait for a reply from those who know more than me. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On 08/01/2020 11:39, Tobias Klausmann via Exim-users wrote: > Yeah, you're right. I presume I need no extra steps for $home > being defined in the context of the transports? In http://exim.org/exim-html-current/doc/html/spec_html/ch-generic_options_for_routers.html on "check_local_user" :- "If the local part is a local user, $home is set from the password data" Or, in http://exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html on "$home" "When the check_local_user option is set for a router, the user’s home directory is placed in $home when the check succeeds". So you need to use check_local_user. Obviously that's not going to work for the "virtual user" case, but it's ok for your case. I'll be trying to invent some verbiage for bits of the docs to guide people away from using $local_part directly... Thanks, Andrew, for identifying the issue. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
Hi! On Wed, 08 Jan 2020, Andrew C Aitchison wrote: > On Wed, 8 Jan 2020, Tobias Klausmann via Exim-users wrote: > > user=$local_part > > verify=false > > transport = local_delivery > > If you have check_local_user you shouldn't need user=$local_part as well. Ah, good point, thanks. > > > And this seems to work. I'll test it for a bit and report back. > > > > Is the use of $local_part in the transports seen as safe, or > > should I cange those to use $home as well? > > On principle I would say change them too. > If $home and /home/$local_part are different directories which do you want ? > The one from the password file/database or the one derived from the > potential hacker's input ? > If /home fills up and you put a new user on a different > disk/partition/volume $home will still work, but /home/$local_part > would need attention ... Yeah, you're right. I presume I need no extra steps for $home being defined in the context of the transports? Best, Tobias -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On Wed, 8 Jan 2020, Tobias Klausmann via Exim-users wrote:
Hi!
On Wed, 08 Jan 2020, Andrew C Aitchison via Exim-users wrote:
I see from your latest message that
/home/$local_part/... is tainted.
Would using $home - and check_local_user to set it - do what you need ?
Indeed that seems to work. I change the earlier config thus:
$ diff -Naur exim-old.conf exim.conf
--- exim-old.conf 2020-01-08 10:02:17.450333630 +0100
+++ exim.conf 2020-01-08 10:01:33.290288221 +0100
@@ -103,18 +103,20 @@
extension_user_verify:
driver = accept
local_part_suffix = -*
- require_files = /home/$local_part/.mail-extensions
+ require_files = $home/.mail-extensions
verify_only
- condition =
${lookup{$local_part_suffix}lsearch{/home/$local_part/.mail-extensions}{yes}{no}}
+ check_local_user
+ condition =
${lookup{$local_part_suffix}lsearch{$home/.mail-extensions}{yes}{no}}
extension_user_delivery_f:
driver = redirect
+ check_local_user
local_part_suffix = -*
- require_files =
/home/$local_part/.mail-extensions:/home/$local_part/.forward
- condition =
${lookup{$local_part_suffix}lsearch{/home/$local_part/.mail-extensions}{yes}{no}}
+ require_files = $home/.mail-extensions:$home/.forward
+ condition =
${lookup{$local_part_suffix}lsearch{$home/.mail-extensions}{yes}{no}}
user=$local_part
check_ancestor
- file = /home/$local_part/.forward
+ file = $home/.forward
allow_filter
allow_fail
verify=false
@@ -125,8 +127,9 @@
extension_user_delivery:
driver = accept
local_part_suffix = -*
- require_files = /home/$local_part/.mail-extensions
- condition =
${lookup{$local_part_suffix}lsearch{/home/$local_part/.mail-extensions}{yes}{no}}
+ check_local_user
+ require_files = $home/.mail-extensions
+ condition =
${lookup{$local_part_suffix}lsearch{$home/.mail-extensions}{yes}{no}}
user=$local_part
verify=false
transport = local_delivery
If you have check_local_user you shouldn't need user=$local_part as well.
And this seems to work. I'll test it for a bit and report back.
Is the use of $local_part in the transports seen as safe, or
should I cange those to use $home as well?
On principle I would say change them too.
If $home and /home/$local_part are different directories which do you want ?
The one from the password file/database or the one derived from the
potential hacker's input ?
If /home fills up and you put a new user on a different
disk/partition/volume $home will still work, but /home/$local_part
would need attention ...
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
Hi!
On Wed, 08 Jan 2020, Andrew C Aitchison via Exim-users wrote:
> I see from your latest message that
> /home/$local_part/... is tainted.
> Would using $home - and check_local_user to set it - do what you need ?
Indeed that seems to work. I change the earlier config thus:
$ diff -Naur exim-old.conf exim.conf
--- exim-old.conf 2020-01-08 10:02:17.450333630 +0100
+++ exim.conf 2020-01-08 10:01:33.290288221 +0100
@@ -103,18 +103,20 @@
extension_user_verify:
driver = accept
local_part_suffix = -*
- require_files = /home/$local_part/.mail-extensions
+ require_files = $home/.mail-extensions
verify_only
- condition =
${lookup{$local_part_suffix}lsearch{/home/$local_part/.mail-extensions}{yes}{no}}
+ check_local_user
+ condition =
${lookup{$local_part_suffix}lsearch{$home/.mail-extensions}{yes}{no}}
extension_user_delivery_f:
driver = redirect
+ check_local_user
local_part_suffix = -*
- require_files =
/home/$local_part/.mail-extensions:/home/$local_part/.forward
- condition =
${lookup{$local_part_suffix}lsearch{/home/$local_part/.mail-extensions}{yes}{no}}
+ require_files = $home/.mail-extensions:$home/.forward
+ condition =
${lookup{$local_part_suffix}lsearch{$home/.mail-extensions}{yes}{no}}
user=$local_part
check_ancestor
- file = /home/$local_part/.forward
+ file = $home/.forward
allow_filter
allow_fail
verify=false
@@ -125,8 +127,9 @@
extension_user_delivery:
driver = accept
local_part_suffix = -*
- require_files = /home/$local_part/.mail-extensions
- condition =
${lookup{$local_part_suffix}lsearch{/home/$local_part/.mail-extensions}{yes}{no}}
+ check_local_user
+ require_files = $home/.mail-extensions
+ condition =
${lookup{$local_part_suffix}lsearch{$home/.mail-extensions}{yes}{no}}
user=$local_part
verify=false
transport = local_delivery
And this seems to work. I'll test it for a bit and report back.
Is the use of $local_part in the transports seen as safe, or
should I cange those to use $home as well?
Best,
Tobias
--
Sent from aboard the Culture ship
GSV Use Psychology
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On Tue, 7 Jan 2020, Tobias Klausmann via Exim-users wrote:
Hey,
I'm running exim in this configuration:
17:28:39 64561 Exim version 4.93.0.3 uid=0 gid=0 pid=64561 D=fff9
Support for: crypteq iconv() IPv6 PAM Perl TCPwrappers OpenSSL Content_Scanning
DANE DKIM DNSSEC Event I18N OCSP PRDR TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch passwd
Authenticators: cram_md5 cyrus_sasl plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Compiler: GCC [9.2.0]
Library version: Glibc: Compile: 2.30
Runtime: 2.30
Library version: BDB: Compile: Berkeley DB 5.3.28: (September 9, 2013)
Runtime: Berkeley DB 5.3.28: (September 9, 2013)
Library version: OpenSSL: Compile: OpenSSL 1.1.1d 10 Sep 2019
Runtime: OpenSSL 1.1.1d 10 Sep 2019
: built on: Tue Dec 3 18:07:39 2019 UTC
Library version: IDN2: Compile: 2.3.0
Runtime: 2.3.0
Library version: Stringprep: Compile: 1.35
Runtime: 1.35
Library version: Cyrus SASL: Compile: 2.1.27
Runtime: 2.1.27 [Cyrus SASL]
Library version: PCRE: Compile: 8.43
Runtime: 8.43 2019-02-23
I have a special user router setup:
extension_user_delivery_f:
driver = redirect
local_part_suffix = -*
require_files =
/home/$local_part/.mail-extensions:/home/$local_part/.forward
condition =
${lookup{$local_part_suffix}lsearch{/home/$local_part/.mail-extensions}{yes}{no}}
user=$local_part
check_ancestor
file = /home/$local_part/.forward
allow_filter
allow_fail
verify=false
file_transport = address_file
pipe_transport = address_pipe
reply_transport = address_reply
I see from your latest message that
/home/$local_part/... is tainted.
Would using $home - and check_local_user to set it - do what you need ?
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
Hi!
On Tue, 07 Jan 2020, Jeremy Harris via Exim-users wrote:
> On 07/01/2020 16:47, Tobias Klausmann via Exim-users wrote:
> > # exim -bt klausman-gen...@schwarzvogel.de
> > LOG: MAIN PANIC
> > attempt to expand tainted string '$rheader_From'
> > LOG: MAIN PANIC
> > attempt to expand tainted string '${if def:header_From {true}{false}}'
> > Sieve error: header string expansion failed in line 3
> > klausman-gen...@schwarzvogel.de -> inbox
> > transport = address_file
>
> Raised bug 2506 for this.
> Please say what platform and who built the exim binary.
$ uname -a
Linux skade 5.5.0-rc3 #15 SMP Fri Dec 27 13:10:59 CET 2019 x86_64 Intel(R)
Core(TM) i7-7700 CPU @ 3.60GHz GenuineIntel GNU/Linux
Exim was built on the same machine, using Gentoo's portage.
Adress test with -d+all and full config (I've also attached my
exim.conf):
08:54:49 2563 Exim version 4.93.0.4 uid=1000 gid=1000 pid=2563 D=fff9
Support for: crypteq iconv() IPv6 PAM Perl TCPwrappers OpenSSL
Content_Scanning DANE DKIM DNSSEC Event I18N OCSP PRDR TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch passwd
Authenticators: cram_md5 cyrus_sasl plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Compiler: GCC [9.2.0]
Library version: Glibc: Compile: 2.30
Runtime: 2.30
Library version: BDB: Compile: Berkeley DB 5.3.28: (September 9, 2013)
Runtime: Berkeley DB 5.3.28: (September 9, 2013)
Library version: OpenSSL: Compile: OpenSSL 1.1.1d 10 Sep 2019
Runtime: OpenSSL 1.1.1d 10 Sep 2019
: built on: Tue Dec 3 18:07:39 2019 UTC
Library version: IDN2: Compile: 2.3.0
Runtime: 2.3.0
Library version: Stringprep: Compile: 1.35
Runtime: 1.35
Library version: Cyrus SASL: Compile: 2.1.27
Runtime: 2.1.27 [Cyrus SASL]
Library version: PCRE: Compile: 8.43
Runtime: 8.43 2019-02-23
08:54:49 2563 Total 11 lookups
WHITELIST_D_MACROS unset
TRUSTED_CONFIG_LIST unset
08:54:49 2563 changed uid/gid: -C, -D, -be or -bf forces real uid
08:54:49 2563 uid=1000 gid=1000 pid=2563
08:54:49 2563 auxiliary group list: 10 12 16 35 78 100 110 237 245 249 250
1000
08:54:49 2563 seeking password data for user "root": cache not available
08:54:49 2563 getpwnam() succeeded uid=0 gid=0
08:54:49 2563 tls_validate_require_cipher child 2564 ended: status=0x0
08:54:49 2563 adding PATH=/sbin:/usr/sbin
08:54:49 2563 configuration file is exim.conf
08:54:49 2563 log selectors = 0ffc 99005032 0003
08:54:49 2563 admin user
08:54:49 2563 dropping to exim gid; retaining priv uid
08:54:49 2563 changing group to 12 failed: Operation not permitted
08:54:49 2563 originator: uid=1000 gid=1000 login=klausman name=Tobias
Klausmann
08:54:49 2563 sender address = klaus...@schwarzvogel.de
08:54:49 2563 Address testing: uid=1000 gid=1000 euid=1000 egid=1000
08:54:49 2563
08:54:49 2563 Testing klausman-gen...@schwarzvogel.de
08:54:49 2563
08:54:49 2563 Considering klausman-gen...@schwarzvogel.de
08:54:49 2563 >>>
08:54:49 2563 routing klausman-gen...@schwarzvogel.de
08:54:49 2563 > virtual router <
08:54:49 2563 local_part=klausman-gentoo domain=schwarzvogel.de
08:54:49 2563 checking domains
08:54:49 2563 search_open: dsearch "/etc/exim/virtual"
08:54:49 2563 search_find: file="/etc/exim/virtual"
08:54:49 2563 key="schwarzvogel.de" partial=-1 affix=NULL starflags=0
08:54:49 2563 LRU list:
08:54:49 2563 5/etc/exim/virtual
08:54:49 2563 End
08:54:49 2563 internal_search_find: file="/etc/exim/virtual"
08:54:49 2563 type=dsearch key="schwarzvogel.de"
08:54:49 2563 file lookup required for schwarzvogel.de
08:54:49 2563 in /etc/exim/virtual
08:54:49 2563 lookup failed
08:54:49 2563 schwarzvogel.de in "dsearch;/etc/exim/virtual"? no (end of
list)
08:54:49 2563 virtual router skipped: domains mismatch
08:54:49 2563 > dnslookup router <
08:54:49 2563 local_part=klausman-gentoo domain=schwarzvogel.de
08:54:49 2563 checking domains
08:54:49 2563 schwarzvogel.de in
"schwarzvogel.de:skade.schwarzvogel.de:i-no.de"? yes (matched "schwarzvogel.de")
08:54:49 2563 schwarzvogel.de in "! +local_domains"? no (matched "!
+local_domains")
08:54:49 2563 dnslookup router skipped: domains mismatch
08:54:49 2563 > new_system_aliases router <
Re: [exim] Sieve filters broken due to tainted expansions?
On 07/01/2020 20:20, Michael Haardt via Exim-users wrote:
> This is quite likely an internal expansion from sieve.c:2327. I did
> not really follow the list recently, so I missed the introduction of
> "tainted" expansions, but the code does this:
>
> expand_header(_value,h);
> header_def=expand_string(string_sprintf("${if def:header_%s
> {true}{false}}",quote(h)));
> if (header_value.character == NULL || header_def == NULL)
Yes, I found that location also. But, so far, all the coding
looks ok - and a quick testcase finds no issues.
> That's to expand and check if a header is defined in order to
> compare it with a value. Perhaps there is a better way to do
> that
That depends somewhat on how much modularity we want to maintain
(here, between the sieve-filter code - which is somewhat of an
add-on - and the exim core code. We could, for instance, provide
and use native interfaces for querying headers rather than going
via the expansions facility). But it's not wrong to be using
those expansions IF the strings being expanded as untainted
(obviously the results could be; in fact _will_ be for headers).
Actually, explaining that has made me wonder... where was the
filter script coming from for Tobias' case, and do we consider
that as a trusted source or a tainted one?I'll have a dig
in that direction.
--
Cheers,
Jeremy
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
> # exim -bt klausman-gen...@schwarzvogel.de
> LOG: MAIN PANIC
> attempt to expand tainted string '$rheader_From'
> LOG: MAIN PANIC
> attempt to expand tainted string '${if def:header_From {true}{false}}'
> Sieve error: header string expansion failed in line 3
This is quite likely an internal expansion from sieve.c:2327. I did
not really follow the list recently, so I missed the introduction of
"tainted" expansions, but the code does this:
expand_header(_value,h);
header_def=expand_string(string_sprintf("${if def:header_%s
{true}{false}}",quote(h)));
if (header_value.character == NULL || header_def == NULL)
That's to expand and check if a header is defined in order to
compare it with a value. Perhaps there is a better way to do
that or a different API should be used now?
Michael
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
On 07/01/2020 16:47, Tobias Klausmann via Exim-users wrote:
> # exim -bt klausman-gen...@schwarzvogel.de
> LOG: MAIN PANIC
> attempt to expand tainted string '$rheader_From'
> LOG: MAIN PANIC
> attempt to expand tainted string '${if def:header_From {true}{false}}'
> Sieve error: header string expansion failed in line 3
> klausman-gen...@schwarzvogel.de -> inbox
> transport = address_file
Raised bug 2506 for this.
Please say what platform and who built the exim binary.
--
Cheers,
Jeremy
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Sieve filters broken due to tainted expansions?
Hi! On Tue, 07 Jan 2020, Tobias Klausmann via Exim-users wrote: > I'm running exim in this configuration: [...] Same problem with 4.93.0.4. best, Tobias -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
