Re: [exim] tainted data issues

[Victor Ustugov via Exim-users]

Heiko Schlittermann via Exim-users wrote on 05.05.2021 23:48:
> Victor Ustugov via Exim-users  (Mi 05 Mai 2021 22:29:32 
> CEST):
 git clone --branch exim-4.94.2+fixes https://github.com/Exim/exim.git
>>>
>>> Sorry my fault, far too many branches, merges, and tags during the
>>> recent days. Branch is exim-4.94.2+taintwarn, which includes the +fixes
>>> and the taintwarn feature.
>>
>> Thank you.
>>
>> As far as I can see, the exim-4.94.2+taintwarn branch includes the code
>> from the exim-4.94.2+fixes branch, doesn't it?
> 
> Exactly. It does include all the stuff in exim-4.94.2+fixes. Please be
> aware, the taintwarn feature is only for mitigation. It will be ignored
> in one of the future versions.

I personally don't need an option allow_insecure_tainted_data.

I'm just testing the building of exim 4.94.2 packages for FreeBSD,
CentOS and Ubuntu with different combinations of patches (for file
parameter in sqlite lookup, exim-4.94.2+fixes, taintwarn code from
exim-4.94.2+taintwarn and from Debian patches).


-- 
Best wishes
Victor Ustugovmailto:vic...@corvax.kiev.ua
Skype ID: corvax_nb   JID: vic...@corvax.kiev.ua
public GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc


-- 
## 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] tainted data issues

[Heiko Schlittermann via Exim-users]

Victor Ustugov via Exim-users  (Mi 05 Mai 2021 22:29:32 
CEST):
> >> git clone --branch exim-4.94.2+fixes https://github.com/Exim/exim.git
> > 
> > Sorry my fault, far too many branches, merges, and tags during the
> > recent days. Branch is exim-4.94.2+taintwarn, which includes the +fixes
> > and the taintwarn feature.
> 
> Thank you.
> 
> As far as I can see, the exim-4.94.2+taintwarn branch includes the code
> from the exim-4.94.2+fixes branch, doesn't it?

Exactly. It does include all the stuff in exim-4.94.2+fixes. Please be
aware, the taintwarn feature is only for mitigation. It will be ignored
in one of the future versions.
-- 
Heiko


signature.asc
Description: PGP signature
-- 
## 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] tainted data issues

[Victor Ustugov via Exim-users]

Heiko Schlittermann via Exim-users wrote on 05.05.2021 21:36:
> Victor Ustugov via Exim-users  (Mi 05 Mai 2021 20:01:56 
> CEST):
>> Heiko Schlittermann via Exim-users wrote on 05.05.2021 19:11:
>>
>>> In case you didn't notice. We've added a new but already deprecated main
>>> config option:
>>>
>>> allow_insecure_tainted_data = yes
>>>
>>> For this option you need to get exim-4.94.2+fixes. This option isn't 
>>> part of 4.94.2!
>>
>> Did you mean
>>
>> git clone --branch exim-4.94.2+fixes https://github.com/Exim/exim.git
> 
> Sorry my fault, far too many branches, merges, and tags during the
> recent days. Branch is exim-4.94.2+taintwarn, which includes the +fixes
> and the taintwarn feature.

Thank you.

As far as I can see, the exim-4.94.2+taintwarn branch includes the code
from the exim-4.94.2+fixes branch, doesn't it?


-- 
Best wishes
Victor Ustugovmailto:vic...@corvax.kiev.ua
Skype ID: corvax_nb   JID: vic...@corvax.kiev.ua
public GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc


-- 
## 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] tainted data issues

[Heiko Schlittermann via Exim-users]

Victor Ustugov via Exim-users  (Mi 05 Mai 2021 20:01:56 
CEST):
> Heiko Schlittermann via Exim-users wrote on 05.05.2021 19:11:
> 
> > In case you didn't notice. We've added a new but already deprecated main
> > config option:
> > 
> > allow_insecure_tainted_data = yes
> > 
> > For this option you need to get exim-4.94.2+fixes. This option isn't 
> > part of 4.94.2!
> 
> Did you mean
> 
> git clone --branch exim-4.94.2+fixes https://github.com/Exim/exim.git

Sorry my fault, far too many branches, merges, and tags during the
recent days. Branch is exim-4.94.2+taintwarn, which includes the +fixes
and the taintwarn feature.


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
-- 
## 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] tainted data issues

[Sander Smeenk via Exim-users]

Quoting Heiko Schlittermann via Exim-users (exim-users@exim.org):

> In case you didn't notice. We've added a new but already deprecated main
> config option:
> allow_insecure_tainted_data = yes

Yes, thanks for your hard work, Heiko!!
I saw that option being discussed / added.
It sure will help people migrate their setups!

Best,
-Sndr.
-- 
| With her marriage she got a new name and a dress.  
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

-- 
## 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] tainted data issues

[Victor Ustugov via Exim-users]

Heiko Schlittermann via Exim-users wrote on 05.05.2021 19:11:

> In case you didn't notice. We've added a new but already deprecated main
> config option:
> 
> allow_insecure_tainted_data = yes
> 
> For this option you need to get exim-4.94.2+fixes. This option isn't 
> part of 4.94.2!

Did you mean

git clone --branch exim-4.94.2+fixes https://github.com/Exim/exim.git

?


I see neither allow_insecure_tainted_data nor
ALLOW_INSECURE_TAINTED_DATA in the exim/ directory.




> This option allowes you to turn the taint errors into warnings and is
> provided to help you in reworking your config into a more secure one.
> Future Exim release (not sure about "future" though) will ignore this
> option.
> 
> Debian 11 includes this patch already. Exim 4.95 will kind of offically
> suppport this option too. But, as said above, it is deprecated already
> today.
> 
> Best regards from Dresden/Germany
> Viele Grüße aus Dresden
> Heiko Schlittermann
> 
> 


-- 
Best wishes
Victor Ustugovmailto:vic...@corvax.kiev.ua
Skype ID: corvax_nb   JID: vic...@corvax.kiev.ua
public GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc


-- 
## 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] tainted data issues

[Heiko Schlittermann via Exim-users]

Sander Smeenk via Exim-users  (Mi 05 Mai 2021 17:10:39 
CEST):
> Quoting Jeremy Harris via Exim-users (exim-users@exim.org):
> 
> > It is far to easy for someone to write a matcher which just
> > untaints everything, disabling the security.  Three people
> > would do that, and one would post it on serverfault.  Then
> > it would be cargo-culted forever.
> 
> You mean like this 'hack'?
> https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/
> 
> 
> TL;DR:
> 
> Late to the party i see, but i was bitten by the new 'tainted
> data'-feature yesterday and after reading this thread, i too would
> really like to see that ${untaint{}{}} idea implemented. 

In case you didn't notice. We've added a new but already deprecated main
config option:

allow_insecure_tainted_data = yes

For this option you need to get exim-4.94.2+fixes. This option isn't 
part of 4.94.2!

This option allowes you to turn the taint errors into warnings and is
provided to help you in reworking your config into a more secure one.
Future Exim release (not sure about "future" though) will ignore this
option.

Debian 11 includes this patch already. Exim 4.95 will kind of offically
suppport this option too. But, as said above, it is deprecated already
today.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
-- 
## 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] tainted data issues

[Sander Smeenk via Exim-users]

Quoting Jeremy Harris via Exim-users (exim-users@exim.org):

> It is far to easy for someone to write a matcher which just
> untaints everything, disabling the security.  Three people
> would do that, and one would post it on serverfault.  Then
> it would be cargo-culted forever.

You mean like this 'hack'?
https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/


TL;DR:
echo '*' >/etc/exim/detaint

DETAINTFILE = /etc/exim/detaint
BADCHARS = \N[^A-Za-z0-9_.-]+\N
SAFEDOMAIN = 
${lookup{${sg{${domain:$h_from:}}{BADCHARS}{_}}}lsearch*,ret=key{DETAINTFILE}}

... Profit!


Late to the party i see, but i was bitten by the new 'tainted
data'-feature yesterday and after reading this thread, i too would
really like to see that ${untaint{}{}} idea implemented. 

I'm all for 'out of the box safety', but making it quite hard to untaint
data is not very user friendly imo. I've yet to find more situations in
my config that break. That's another peeve: there is no warning or error
until you run into it.

My frustration mostly comes from the fact that my config was working for
years, untouched, then suddenly it doesn't anymore and there is no clear
guidance on how to fix this mess as others in this thread reported too.

My situation was much like others reported, the dkim_key lookup, and can
be fixed by doing that dsearch lookup thing.

Providing a list of reported taint-issues and acompanying fixes like
that would be of great help to people that were rockin' Exim configs for
years and forgot about all the ${{acc}olade{mess}} therein.


Meh.
-Sandr.
-- 
| Broken pencils are pointless.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

-- 
## 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] tainted data issues

[Jeremy Harris via Exim-users]

On 23/11/2020 14:20, Gary Stainburn via Exim-users wrote:

   data = ${lookup{$local_part}lsearch{/etc/aliases.d/$domain}}


Don't use a tainted name as the filename for that lsearch.

Assuming that not doing the lsearch when the file doesn't exist
is what you want: use a dsearch in that directory to verify
that the file exists.  Use the "return whole path" variant, so
that you can just feed that to lsearch.
--
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] tainted data issues

[Gary Stainburn via Exim-users]

Okay, so I've read everything and I'm now lost.

I've got a router for non-standard domains, i.e. domains I manage that 
don't follow the main config. The domainlist is defined at the top of 
the config file, so that isn't tainted.  Below are the original and 
modified routers. My problem is that EXIM is still saying that the 
filename  is tainted.


What do I need to do?

Original version of router

non_std_aliases:
  driver = redirect
  domains = +non_std_domains
  allow_fail
  allow_defer
  data = ${lookup{$local_part}lsearch{/etc/aliases.d/$domain}}
  file_transport = address_file
  pipe_transport = address_pipe

Modified version

non_std_aliases:
  driver = redirect
  domains = +non_std_domains
  allow_fail
  allow_defer
  data = ${if 
exits{/etc/aliases.d/$domain}{${lookup{$local_part}lsearch{/etc/aliases.d/$domain}}}

  file_transport = address_file
  pipe_transport = address_pipe


--
## 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] tainted data issues

[Heiko Schlittermann via Exim-users]

Mark Elkins via Exim-users  (Do 12 Nov 2020 07:22:44 CET):
> One could do this for a punycode version of the domain name but the address
> part before an '@' can be UTF8 - such as "café". Please don't break any
> internationalised addresses (Universal Acceptance and all that). I'm
> wondering if an inverse check could be done, as in look for anything bad?
> (e.g. Double dots and slashes)

IMHO we're not going to check if an address (local_part, domain) is
valid. (For local_parts we have example ACL entries)

We're talking about the usage the "taintness" data. And even a valid
local_part is tainted. And, depending on how I use it, the valid local
part may be dangerous (e.g. for constructing path names).

And - as I pointed out already, not the pure existence/non-existence of 
characters is enough to judge, if a given value can be considered as
safe. Though there might be valid use cases, where pure filtering is
sufficient (phone numbers), and other use cases, where the position of
the characters is important (pathnames).

So, I vote for methods to check if a given tainted value is safe for a
given use case. May this be done by lookups, or by specialized
functions.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
-- 
## 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] tainted data issues

[Ian Zimmerman via Exim-users]

On 2020-11-11 18:14, Jeremy Harris wrote:

> > I will not argue with the rest of your post, but it is not a _modifier_
> > if it is always on.
> 
> Ah.  Would an expansion condition be sufficient?  So you could write
> 
>   ${if  tainted{my_suspect_expansion}  {expand_this} {expand_that}}
> 
> That would be simple to code and test.

I think this would be an improvement, yes. Then again, I seem to have
fewer quarrels with the current situation than others in this thread.

-- 
Ian

-- 
## 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] tainted data issues

[Sebastian Nielsen via Exim-users]

About 3 - why not? I propose a new untaint/filter function in ADDITION to what 
already exist, so people can choose what fits the situation best.

Sometimes, you know beforehand what email adress to expect on recipient, then a 
lookup is fine and you can accept any characters.

Sometimes, you "mint" email adresses based on a external factor (think 
Email-2-SMS or mailinator.com like service, or even include IP adresses in 
localpart - for example for a local network messaging system) - then you need 
to be able to allow any email adress that follows a specific set of strict 
rules - to prevent dangerous data to compromise the server.
What I propose with the filters.

Also notice - my proposed filters will never fail, it will only delete 
dangerous characters, meaning it will "neuter" bad data, not reject it.

And if the system administrators want to reject bad data instead of "neuter it" 
- he have to compare the unfiltered data to filtered data, and reject if they 
don't match, else return the filtered variant (which is equal to the unfiltered 
if no bad characters were found)

Meaning any legit filtered characters will not break internationalization.

Also such a filter, as I said, can be very useful for non-taint filtering too - 
for example filtering out bad characters from subjects or headers, even if 
tainted data is accepted there, there is still reasons to filter things like 
that to prevent certain email clients to crash.

-Ursprungligt meddelande-
Från: Andrew C Aitchison via Exim-users  
Skickat: den 12 november 2020 16:04
Till: exim-users@exim.org
Ämne: Re: [exim] tainted data issues


On Thu, 12 Nov 2020, Mike Tubby via Exim-users wrote:

> Here's a proposal for a compromise in an attempt to satisfy these, 
> competing, requirements with a phased approach:
>
> 1. Publish a roadmap for Exim - likely things to arrive in 4.95, 4.96, 
> 4.97 ... and that there will be an Exim 5.0 out in roughly XX months.  
> This doesn't have to be stuck to - its forward looking not a 'promise' 
> but can include item (5) below.
>
> 2. Keep the tainted data model as it is now
>
> 3. Don't give the user's new untaint methods that fix one thing and 
> potentially break another, e.g. internationalisation
>
> 4. Document tainted data more fully:
>
> * what tainted data is
> * what can go wrong if you trust it when you shouldn't
> * why you need to change
> * examples of configurations and recommendations
>
> Ensure the documentation includes the road-signs to the right way to 
> do things to avoid cargo-cult
>
> 5. Add a new config variable:
>
> taint_mode = warn | enforce
>
> which is initially defaults to 'warn' and which bleaches to 
> mainlog/paniclog or even stdout on start warning:
>
> a) of the perils of tainted data;
> b) tells the user this this feature is going to be removed in 
> a future release
> c) points to the documentation (3)
>   Eg:
>Exim: Configuration uses tainted data which is currently 
> allowed may be dangerous. This will be removed in a future release. 
> For info see https://exim.org/tainted_data.html
>
> At some later release (4.96, 4.97 ?) switch from the default of 
> 'warn' to the default of 'enforce', effectively allowing the user to 
> swim against the tide by switching back to 'warn' if they must.
>
> Implement the taint_mode with a sun-set, i.e planned removal at Exim 5.0.
>
> 6. Implement Jeremy's relatively light weight:
>
>   ${if  tainted{my_suspect_expansion}  {expand_this} 
> {expand_that}}
>
>   Which he said would be simple to code and test and allow some 
> workarounds to be implemented for some use cases.
>
> 7. Publicity.

Generally good. Thanks Mike.

Some points:

A/ I believe that one reason we have got into this position is that "suspect" 
data is currently being used in many ways that the main developers had not 
imagined.
*** This means that other people are in a better position then Jeremy etc.
*** to write (at least one pass of) the new documentation.

B/ Given that the likes of Ubuntu are now shipping v4.94, would it not be 
reasonable to default to
taint_mode = enforce
  - anyone who is up to date already has this, so that is least surprise ?
If 4.95 bleats unless taint_mode is explicitly set to something, we will get 
some free publicity, and the user will know to set taint_mode = warn until they 
have addresses the issue.
The later release (4.96, 4.97 ?) will then merely need to bleat if taint_mode 
is set to "warn".
(I am tempted to suggest that this should be a persistent bleat, like the
   Warning: No server certificate defined; will use a selfsigned one.
 Suggested action: either install a certificate or change 
tls_advertise_hosts option
message.)

C/ I see 6. ${if 

Re: [exim] tainted data issues

[Sebastian Nielsen via Exim-users]

Thats up to the system administrator to configure.
Thats why I propose that it should be possible to specify non-ascii characters 
like \xXX to allow UTF8 characters to be specfied. Thus system administrators 
can configure this based on locality, so those in sweden would accept åäöÅÄÖ as 
recipient and so on.

Thats why I suggest it to be custom, so system administrators in different 
countries can configure it differently.

As I said, this untaint/filter method could be provided in ADDITION to whatever 
exist, so it won't break anything.

-Ursprungligt meddelande-
Från: Mark Elkins via Exim-users  
Skickat: den 12 november 2020 07:31
Till: 'Mailing List' 
Ämne: Re: [exim] tainted data issues

One could do this for a punycode version of the domain name but the address 
part before an '@' can be UTF8 - such as "café". Please don't break any 
internationalised addresses (Universal Acceptance and all that). I'm wondering 
if an inverse check could be done, as in look for anything bad? (e.g. Double 
dots and slashes)

On 2020/11/10 22:45, Sebastian Nielsen via Exim-users wrote:
> I think as I said, provide a untaint tool, that allows custom data to 
> verify against.
>
> Like:
> ${untaint(${var},
> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789")}
>
> Regardless of if ${var} is tained or not, the result of ${untaint} is 
> always untainted.
>
> The character string, is then what to filter against - all characters 
> not on that particular list, will be removed from ${var} silently 
> before passing it on.
>
> This allows system administrators, to do entirely custom checks 
> against dangerous data, since in all cases where tainted data becomes 
> a security issue, is when delimiter characters is inserted in the text 
> to escape out of the enviroment that the command or whatever is 
> executed in, and be able to execute arbitary commands or write in arbitary 
> locations.
>
> Its very important that the function itself is "safe" - meaning it 
> should not be possible in ANY way for tainted data to "leak through" 
> the filter, ergo it must not be possible for any character not on 
> administrator's list, to end up in the return of the untaint function.
>
> Also the filter list itself, must also be done in such a way variable 
> expansion never happens in the filter list - only way to specify a 
> filter list, is to manually specify it in config file.
>
>
> This gives most flexibility, and also encourages security by making it 
> easy to filter data before passing it on, making it a "habit" for 
> system administrators.
> Then it will be a habit to always ${untaint} even in cases where 
> untainted data is not required, incresing security even further.
>
> In the above example, if ${var} contains 
> "Sebastian/Users/f...@somewhere.com"  the result of the untaint 
> operation with that particular filter list would be 
> "SebastianUsersfilesomewherecom"
> which is a completely safe string to pass on to filesystem.
>
> To make it even easier for system administrators, make premade filter 
> lists
> like:
> %%FILESYSTEM%% = Contains a list of characters that is safe for use in 
> functions that read or write to filesystem.
> %%SYSTEM%% = Containst a list of charactes that is safe to pass on to 
> a live terminal, like when running system commands or similiar.
> %%SQL%% = Contains a list of characters that is safe to pass on to a 
> raw SQL prompt without rsik of injection.
> %%HTML%% = Contains a list of characters that is safe to output to a 
> web browser without security risks.
> %%LOCALPART%% = Contains a list of characters safe in localpart of a 
> email adress.
> %%HOSTPART%% = Contains a list of characters safe to use in a DNS name 
> or host part of a adress including IP literals.
> %%FULLEMAIL%% = Contains a list of characters that is allowed and safe 
> to use in a full email adress.
>
> So writing:
> ${untaint(${var}, "%%SQL%%")}
>
> Would filter ${var} in such a way that its safe to pass on to a raw 
> SQL string without injection risk.
>
> Note that these %% strings is NOT string expansions - instead a 
> customized system for specifying pre-made filters, preventing 
> variables from being accidentially expanded and used in a filter list, 
> which in itself is a big security risk, since then filter lists could be 
> modifyed from the outside.
>
> However, \xXX should be expanded of course, so people can write 
> characters that don't exist on the keyboard, in some cases they are useful.
>
>
> Such a untaint function should be easy to implement.
> And would make exim much more secure, as its a very easy function, 
> making it a habit to use the function by sy

Re: [exim] tainted data issues

[Andrew C Aitchison via Exim-users]

On Thu, 12 Nov 2020, Mike Tubby via Exim-users wrote:

Here's a proposal for a compromise in an attempt to satisfy these, competing, 
requirements with a phased approach:


1. Publish a roadmap for Exim - likely things to arrive in 4.95, 4.96, 4.97 
... and that there will be an Exim 5.0 out in roughly XX months.  This 
doesn't have to be stuck to - its forward looking not a 'promise' but can 
include item (5) below.


2. Keep the tainted data model as it is now

3. Don't give the user's new untaint methods that fix one thing and 
potentially break another, e.g. internationalisation


4. Document tainted data more fully:

* what tainted data is
* what can go wrong if you trust it when you shouldn't
* why you need to change
* examples of configurations and recommendations

Ensure the documentation includes the road-signs to the right way to do 
things to avoid cargo-cult


5. Add a new config variable:

taint_mode = warn | enforce

which is initially defaults to 'warn' and which bleaches to 
mainlog/paniclog or even stdout on start warning:


a) of the perils of tainted data;
b) tells the user this this feature is going to be removed in a 
future release

c) points to the documentation (3)
  Eg:
   Exim: Configuration uses tainted data which is currently allowed may 
be dangerous. This will be removed in a future release. For info see 
https://exim.org/tainted_data.html


At some later release (4.96, 4.97 ?) switch from the default of 'warn' to 
the default of 'enforce', effectively allowing the user to swim against the 
tide by switching back to 'warn' if they must.


Implement the taint_mode with a sun-set, i.e planned removal at Exim 5.0.

6. Implement Jeremy's relatively light weight:

  ${if  tainted{my_suspect_expansion}  {expand_this} {expand_that}}

  Which he said would be simple to code and test and allow some workarounds 
to be implemented for some use cases.


7. Publicity.


Generally good. Thanks Mike.

Some points:

A/ I believe that one reason we have got into this position is that
"suspect" data is currently being used in many ways that the main
developers had not imagined.
*** This means that other people are in a better position then Jeremy etc.
*** to write (at least one pass of) the new documentation.

B/ Given that the likes of Ubuntu are now shipping v4.94,
would it not be reasonable to default to
   taint_mode = enforce
 - anyone who is up to date already has this, so that is least surprise ?
If 4.95 bleats unless taint_mode is explicitly set to something, we will
get some free publicity, and the user will know to set taint_mode = warn
until they have addresses the issue.
The later release (4.96, 4.97 ?) will then merely need to bleat
if taint_mode is set to "warn".
(I am tempted to suggest that this should be a persistent bleat, like the
  Warning: No server certificate defined; will use a selfsigned one.
Suggested action: either install a certificate or change 
tls_advertise_hosts option
message.)

C/ I see 6. ${if  tainted{ as primarily a debugging feature;
once {expand_this} and {expand_that} are pinned down for an installation,
I believe that {my_suspect_expansion} will usually turn out to be a constant.


--
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] tainted data issues

[Mike Tubby via Exim-users]

On 11/11/2020 18:31, Chris Siebenmann via Exim-users wrote:

  Jeremy Harris:

   Semi-radical: provide an ACL, router, and transport modifier that
checks some variable or content for dangerous contents

We have that.  All data provided by an untrusted source, described
as "tainted" for a shorthand.

  Tainted variables contain potentially dangerous contents, not actually
dangerous contents. Most of the time, the contents of tainted variables
are not dangerous, but sometimes they are. I think that it would be
useful for Exim to provide assistance in telling the two apart.

  I say this because I strongly believe that people are going to
write Exim configuration code that de-taints variables in brute
force ways (and the more that Exim doesn't provide mechanisms to
do relatively arbitrary 'safe' de-tainting, the more that people
are going to do so). I think it's relatively important to let
people guard these de-taintings with safety checks, such as 'is
there dangerous content here'.

  Also, even with relatively safe de-tainting, sometimes I would rather
reject funny content immediately. This is actually a relatively popular
thing to do today in ad-hoc ways; for example, the Debian 'split' Exim
configuration has for years shipped with a set of checks for dangerous
characters in local parts. Sysadmins can maybe write these checks
in Exim configurations themselves, but in ad-hoc ways and sysadmins
probably don't know as much about what things are dangerous (or valid)
in various conditions as other people do.

- cks




I have read all of the contributions to this discussion with interest 
and there are clearly contradictions between:


 * implementing good security
 * not breaking existing existing installations
 * simplicity for users and maintainers
 * avoiding giving people guns for them to shoot themselves in the foot
 * ending up with cargo-cult answers on Stack Exchange

We also know that inertia in the community often means that deployment 
and distros are 12-18 months or more behind the 'head' version.


We don't know how many installations of Exim are out there - perhaps 
hundreds of thousands or more. An abrupt change could be highly 
problematic and also cause reputational damage.



Here's a proposal for a compromise in an attempt to satisfy these, 
competing, requirements with a phased approach:


1. Publish a roadmap for Exim - likely things to arrive in 4.95, 4.96, 
4.97 ... and that there will be an Exim 5.0 out in roughly XX months.  
This doesn't have to be stuck to - its forward looking not a 'promise' 
but can include item (5) below.


2. Keep the tainted data model as it is now

3. Don't give the user's new untaint methods that fix one thing and 
potentially break another, e.g. internationalisation


4. Document tainted data more fully:

 * what tainted data is
 * what can go wrong if you trust it when you shouldn't
 * why you need to change
 * examples of configurations and recommendations

    Ensure the documentation includes the road-signs to the right way 
to do things to avoid cargo-cult


5. Add a new config variable:

        taint_mode = warn | enforce

    which is initially defaults to 'warn' and which bleaches to 
mainlog/paniclog or even stdout on start warning:


        a) of the perils of tainted data;
        b) tells the user this this feature is going to be removed in a 
future release

        c) points to the documentation (3)

    Eg:

       Exim: Configuration uses tainted data which is currently allowed 
may be dangerous. This will be removed in a future release. For info see 
https://exim.org/tainted_data.html


    At some later release (4.96, 4.97 ?) switch from the default of 
'warn' to the default of 'enforce', effectively allowing the user to 
swim against the tide by switching back to 'warn' if they must.


    Implement the taint_mode with a sun-set, i.e planned removal at 
Exim 5.0.


6. Implement Jeremy's relatively light weight:

      ${if  tainted{my_suspect_expansion}  {expand_this} {expand_that}}

    Which he said would be simple to code and test and allow some 
workarounds to be implemented for some use cases.


7. Publicity.



Mike
--
## 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] tainted data issues

[Mark Elkins via Exim-users]

One could do this for a punycode version of the domain name but the 
address part before an '@' can be UTF8 - such as "café". Please don't 
break any internationalised addresses (Universal Acceptance and all 
that). I'm wondering if an inverse check could be done, as in look for 
anything bad? (e.g. Double dots and slashes)


On 2020/11/10 22:45, Sebastian Nielsen via Exim-users wrote:

I think as I said, provide a untaint tool, that allows custom data to verify
against.

Like:
${untaint(${var},
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789")}

Regardless of if ${var} is tained or not, the result of ${untaint} is always
untainted.

The character string, is then what to filter against - all characters not on
that particular list, will be removed from ${var} silently before passing it
on.

This allows system administrators, to do entirely custom checks against
dangerous data, since in all cases where tainted data becomes a security
issue, is when delimiter characters is inserted in the text to escape out of
the enviroment that the command or whatever is executed in, and be able to
execute arbitary commands or write in arbitary locations.

Its very important that the function itself is "safe" - meaning it should
not be possible in ANY way for tainted data to "leak through" the filter,
ergo it must not be possible for any character not on administrator's list,
to end up in the return of the untaint function.

Also the filter list itself, must also be done in such a way variable
expansion never happens in the filter list - only way to specify a filter
list, is to manually specify it in config file.


This gives most flexibility, and also encourages security by making it easy
to filter data before passing it on, making it a "habit" for system
administrators.
Then it will be a habit to always ${untaint} even in cases where untainted
data is not required, incresing security even further.

In the above example, if ${var} contains
"Sebastian/Users/f...@somewhere.com"  the result of the untaint operation
with that particular filter list would be "SebastianUsersfilesomewherecom"
which is a completely safe string to pass on to filesystem.

To make it even easier for system administrators, make premade filter lists
like:
%%FILESYSTEM%% = Contains a list of characters that is safe for use in
functions that read or write to filesystem.
%%SYSTEM%% = Containst a list of charactes that is safe to pass on to a live
terminal, like when running system commands or similiar.
%%SQL%% = Contains a list of characters that is safe to pass on to a raw SQL
prompt without rsik of injection.
%%HTML%% = Contains a list of characters that is safe to output to a web
browser without security risks.
%%LOCALPART%% = Contains a list of characters safe in localpart of a email
adress.
%%HOSTPART%% = Contains a list of characters safe to use in a DNS name or
host part of a adress including IP literals.
%%FULLEMAIL%% = Contains a list of characters that is allowed and safe to
use in a full email adress.

So writing:
${untaint(${var}, "%%SQL%%")}

Would filter ${var} in such a way that its safe to pass on to a raw SQL
string without injection risk.

Note that these %% strings is NOT string expansions - instead a customized
system for specifying pre-made filters, preventing variables from being
accidentially expanded and used in a filter list, which in itself is a big
security risk, since then filter lists could be modifyed from the outside.

However, \xXX should be expanded of course, so people can write characters
that don't exist on the keyboard, in some cases they are useful.


Such a untaint function should be easy to implement.
And would make exim much more secure, as its a very easy function, making it
a habit to use the function by system administrators.

YES - it is possible to "shoot yourself in the foot" with the function by
specofying characters that is unsafe for that particular usage, but then the
responsibility is on the system administrator.


Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: Michael Haardt via Exim-users  
Skickat: den 10 november 2020 20:16

Till: Jeremy Harris via Exim-users
Ämne: Re: [exim] tainted data issues

Jeremy Harris via Exim-users  wrote:

The one major hole I know of is for the creation of a mailbox file,
first time, for an account.

After having reviewed a number of configurations, I am sure there is more.

While I am not pleased with the design of verifying tainted data, or
introducing it in such an invasive manner without a new major version, the
need of doing so absolutely exists.  That said, the current design is usable
and it solves the problem.  Using it may either convince us of being the
best solution, or show which specific alternative is better.

The ongoing configuration reviews certainly uncovered potential problems, so
rolling back is not an optio

Re: [exim] tainted data issues

[Sebastian Nielsen via Exim-users]

>>I think it's relatively important to let people guard these de-taintings
with safety checks, such as 'is there dangerous content here'.

Agree, thats why I propose a simple character filter that also de-taints
variables.

>> I feel that people should not need to be experts in knowing what are safe
and dangerous characters and character sequences in order to create safe
Exim configurations.

Agreed, thats why I also propose the "standard sets" like %%SQL%%,
%%FILESYSTEM%% etc that give safe character sets to use with a particular
use case.
So theres both "standard" proven ways to do it, but also custom ways to do
it if you have special use cases.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
## 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] tainted data issues

[Chris Siebenmann via Exim-users]

 Jeremy Harris:
> >   Semi-radical: provide an ACL, router, and transport modifier that
> > checks some variable or content for dangerous contents
> 
> We have that.  All data provided by an untrusted source, described
> as "tainted" for a shorthand.

 Tainted variables contain potentially dangerous contents, not actually
dangerous contents. Most of the time, the contents of tainted variables
are not dangerous, but sometimes they are. I think that it would be
useful for Exim to provide assistance in telling the two apart.

 I say this because I strongly believe that people are going to
write Exim configuration code that de-taints variables in brute
force ways (and the more that Exim doesn't provide mechanisms to
do relatively arbitrary 'safe' de-tainting, the more that people
are going to do so). I think it's relatively important to let
people guard these de-taintings with safety checks, such as 'is
there dangerous content here'.

 Also, even with relatively safe de-tainting, sometimes I would rather
reject funny content immediately. This is actually a relatively popular
thing to do today in ad-hoc ways; for example, the Debian 'split' Exim
configuration has for years shipped with a set of checks for dangerous
characters in local parts. Sysadmins can maybe write these checks
in Exim configurations themselves, but in ad-hoc ways and sysadmins
probably don't know as much about what things are dangerous (or valid)
in various conditions as other people do.

- 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] tainted data issues

[Jeremy Harris via Exim-users]

On 11/11/2020 16:29, Ian Zimmerman via Exim-users wrote:

On 2020-11-11 13:16, Jeremy Harris wrote:


Semi-radical: provide an ACL, router, and transport modifier that
checks some variable or content for dangerous contents



We have that.  All data provided by an untrusted source, described
as "tainted" for a shorthand.


I will not argue with the rest of your post, but it is not a _modifier_
if it is always on.


Ah.  Would an expansion condition be sufficient?  So you could write

  ${if  tainted{my_suspect_expansion}  {expand_this} {expand_that}}

That would be simple to code and test.
--
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] tainted data issues

[Michael Haardt via Exim-users]

Jeremy Harris via Exim-users  wrote:

> >   Radical: $local_part, $domain, and similar tainted variables should
> > be automatically un-tainted once they pass a check that would generate
> > the untainted version of the variable.

> On the other side of the coin, re-using the same variables and
> changing the taint-status of the content makes problem-discovery
> harder.  When you do run into a taint issue, under the "same variables"
> approach, it is not immediately obvious from the config file source
> that you forgot to de-taint the value.

The problem is that right now it is not obvious which variables are
tainted, there are no *_data variables for all tainted variables and
there is no generic mechanism to verify a tainted variable.

> >   Radical: in ACLs, verifying the receiver or sender address through
> > 'verify = ' should optionally un-taint $local_part, $domain,
> > and so on.
> 
> Considerably more complex in its security aspects; more than I want
> to think about at this time.  Maybe one for the future.

>From the little experience so far it shows that verification of tainted
variables is logically tied to routers.  A central ACL does not
match that structure.

Domains and local_parts are checked very early in the router and I
believe verifying variables early in the router is the right place.

The problem is that the variable verification side effect is neither
obvious nor universal usable for all variables, and I am not
sure we need copies of all variables that are tainted.

> >   Radical: provide an ACL and/or router modifier that immediately
> > un-taints $local_part,
> 
> No.  As responded to elsewhere: providing an overly-obvious way
> to game the security means no security.

To me, half way there would be right: Add a new option for routers that
is checked before all other options and verifies variables, detainting
them instead of copying them.  The actual verification using a lookup
is fine to me.  It was already shown how to use lookups against regular
expressions, no need to make it easier than that.

To avoid confusion, as verification has its own meaning in Exim, it
could be called validation:

  validate_local_part_suffix = ${lookup {$local_part_suffix} }

That way it is obvious which variables are valid and which are not,
validation stays pretty much where it is now and it is clear that in
order to use a variable at a critical place, it must be validated first.
No hidden side effect.

Like local_parts/domains right now, only generic, without creating a
copy of the variable and applicable to all tainted variables.

It would be cool if we had something that validates all variables used
as the key of the lookup for query lookups, again allowing single query
lookups that make use of local part, domain and possibly other variables.
The current need to duplicate lookups makes configurations less clear
than they could be.

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] tainted data issues

[Ian Zimmerman via Exim-users]

On 2020-11-11 13:16, Jeremy Harris wrote:

> > Semi-radical: provide an ACL, router, and transport modifier that
> > checks some variable or content for dangerous contents

> We have that.  All data provided by an untrusted source, described
> as "tainted" for a shorthand.

I will not argue with the rest of your post, but it is not a _modifier_
if it is always on.

-- 
Ian

-- 
## 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] tainted data issues

[Chris Siebenmann via Exim-users]

> Yes, but its a positive match only - meaning you have to explicitly
> specify allowed characters.The function should NOT be able to
> specify forbidden characters - as then it would ve easy to miss bad
> characters.If an sysadmin then writes a filter which is too broad -
> its his own fault.

 History has vividly demonstrated that providing a toolkit and asking
people to build their own secure implementation from it does not create
effective security (although it does let you blame a different set of
people for the resulting insecurity). Many people will either make
mistakes or not know all of the surprises and traps that are lurking,
and so won't know to counter them.

 Effective security is almost always created by a few people who know
the area very well spending a bunch of time to thoroughly explore all
of the dark corners, then building something with as few options as
possible (ideally none).

 Or to put it another way: I feel that people should not need to be
experts in knowing what are safe and dangerous characters and character
sequences in order to create safe Exim configurations. If they have
to be such experts, there will be a lot of unsafe Exim configurations
created.

 I think it's potentially sensible to provide an escape hatch, but
I don't think that it should be the only way to do it; I think it
should only be something that you resort to if you have highly unusual
needs. And I share Jeremy Harris's worry that it will be cargo-culted
and copied widely, even then.

(Possibly unlike Jeremy Harris, I feel that if Exim provides no such
safe-ish general un-tainting, people will still find ways to do it and
then cargo-cult it. People are going to cargo-cult answers for this; the
only question is whether Exim can help make that as safe as possible.)

- 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] tainted data issues

[Andrew C Aitchison via Exim-users]

On Wed, 11 Nov 2020, Sebastian Nielsen via Exim-users wrote:


Yes, but its a positive match only - meaning you have to explicitly
specify allowed characters.The function should NOT be able to
specify forbidden characters - as then it would ve easy to miss bad
characters.If an sysadmin then writes a filter which is too broad -
its his own fault.


Even that has pitfalls once you add non-ascii characters.


I mean - I have a Email-to-sms gateway which pipes
data to a system script.@sebbe.eu is interpreted as outgoing
SMS.With the current structure, you need to add every number you
want to SMS as whitelist - as you need to do a successful lookup to
untaint.Its much better to be able to specify that localpart can
only contain numbers to be permitted to be piped to the script - no
security risk as nobody can escape out of a shell command with only
0-9 to their disposal.


I wonder whether a specific "telephone number" option would make sense ?
Do we allow the international code "+", or the pause (which can be
used in fax numbers) 
https://www.dummies.com/consumer-electronics/smartphones/droid/how-to-add-pauses-when-dialing-a-number-on-your-android-phone/ ?


--
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] tainted data issues

[Sebastian Nielsen via Exim-users]

Yes, but its a positive match only - meaning you have to explicitly specify 
allowed characters.The function should NOT be able to specify forbidden 
characters - as then it would ve easy to miss bad characters.If an sysadmin 
then writes a filter which is too broad - its his own fault.I mean - I have a 
Email-to-sms gateway which pipes data to a system script.@sebbe.eu is 
interpreted as outgoing SMS.With the current structure, you need to add every 
number you want to SMS as whitelist - as you need to do a successful lookup to 
untaint.Its much better to be able to specify that localpart can only contain 
numbers to be permitted to be piped to the script - no security risk as nobody 
can escape out of a shell command with only 0-9 to their disposal.
 Originalmeddelande Från: Jeremy Harris via Exim-users 
 Datum: 2020-11-11  14:00  (GMT+01:00) Till: 
exim-users@exim.org Ämne: Re: [exim] tainted data issues On 10/11/2020 20:45, 
Sebastian Nielsen via Exim-users wrote:> I think as I said, provide a untaint 
tool, that allows custom data to verify> against.> > Like:> ${untaint(${var},> 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789")}No; this is a 
bad idea.It is far to easy for someone to write a matcher which justuntaints 
everything, disabling the security.  Three peoplewould do that, and one would 
post it on serverfault.  Thenit would be cargo-culted forever.-- 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/

smime.p7s
Description: S/MIME Cryptographic Signature
-- 
## 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] tainted data issues

[Jeremy Harris via Exim-users]

On 10/11/2020 19:45, Chris Siebenmann via Exim-users wrote:

  Moderate: there should be a full chapter in the Exim documentation on
tainting and how to deal with it. This should cover the security risks
that it's there to deal with, common configuration snippets that are now
a problem, and how to deal with tainting and de-tainting data in common
configuration needs. Right now there is not even an explicit subsection
for tainting in the Security Considerations chapter.

(If in the process of writing this chapter things are difficult to
explain or the configuration changes seem awkward, well, that is a
sign of where improvements are needed.)


The problem I had in writing documentation was in the opposite
direction: Exim's taint-tracking is a very simple concept and
does not take many words to describe.  Nor does the ethos of
de-taint methods.

It didn't take anything near a chapter.  Please see the current
(post-4.94 release) state of the documentation, posted at

https://people.exim.org/jeremy.harris/docs/HEAD/exim-html-4.94-RC999/exim-html-current/doc/html/spec_html/




  Semi-radical: there should be a configuration file option that turns
taint errors into warnings that do not stop processing but that are
merely logged to the main log or perhaps also the paniclog.


As noted elsewhere, possible though expensive in developer time.



(It would be nice if all system administrators had automated test
suites that completely cover their entire Exim configuration. If people
think that having such a test suite should be required for reliable
Exim version upgrades, perhaps someone should write a chapter for the
Exim documentation on how to create and operate it, and also how to
measure the configuration file coverage so that you know you have 100%
coverage.)


"Someone" needs to volunteer, obviously.




  An optional but nice extra would be a third choice for this option,
which generates 'this would have been rejected' warnings if the contents
of the tainted variable being used seem harmless, but force hard errors
if it appears to have dangerous contents (whatever the Exim developers
consider that to be).


More complexity is bad.  Asking developers to think harder probably
also isn't good.




  Semi-radical: provide an ACL, router, and transport modifier that
checks some variable or content for dangerous contents


We have that.  All data provided by an untrusted source, described
as "tainted" for a shorthand.


 (possibly in

several variations),


No, complexity again.



  Radical: $local_part, $domain, and similar tainted variables should
be automatically un-tainted once they pass a check that would generate
the untainted version of the variable. Forcing system administrators
to switch which variable they use has two problems. First, it is
make-work, since the two variables are essentially bolted together
(and if they are not, it is likely to surprise people, for example if
you somehow get $local_part changed but $local_part_data stays with
an old value). Second, it is part of what makes it impossible to have
a configuration file that works in both an old un-tainted Exim and
a new tainting Exim, since $local_part_data does not exist in older
Exims. Forcing configuration file updates at the same time as Exim
version updates complicates sysadmin life.


On the other side of the coin, re-using the same variables and
changing the taint-status of the content makes problem-discovery
harder.  When you do run into a taint issue, under the "same variables"
approach, it is not immediately obvious from the config file source
that you forgot to de-taint the value.

This one is open to more opinions.  I chose the "different variables"
approach



  Radical: in ACLs, verifying the receiver or sender address through
'verify = ' should optionally un-taint $local_part, $domain,
and so on.


Considerably more complex in its security aspects; more than I want
to think about at this time.  Maybe one for the future.



  Radical: provide an ACL and/or router modifier that immediately
un-taints $local_part,


No.  As responded to elsewhere: providing an overly-obvious way
to game the security means no security.
--
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] tainted data issues

[Jeremy Harris via Exim-users]

On 10/11/2020 20:45, Sebastian Nielsen via Exim-users wrote:

I think as I said, provide a untaint tool, that allows custom data to verify
against.

Like:
${untaint(${var},
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789")}


No; this is a bad idea.

It is far to easy for someone to write a matcher which just
untaints everything, disabling the security.  Three people
would do that, and one would post it on serverfault.  Then
it would be cargo-culted forever.
--
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] tainted data issues

[Jeremy Harris via Exim-users]

On 10/11/2020 09:33, Mike Tubby via Exim-users wrote:
I am all for improved security but a single "step change" that breaks 
existing configurations is IMHO going too far.


     taint_mode = off | warn | enforce


Warn and enforce, I could see as an interim measure.
But only interim - to be remove at some future release.

I do not think it should be possible to turn off. This
would make it pointless.


The coding to implement this would not be too hard.
The regression-testing impact is somewhat higher,
and I am not particularly incentivised to spend the effort,
personally.  Do I hear volunteers?

There is also the forward-committed work of removing
it all later (and handling the same set of complaints
yet again).  Otherwise it remains as a bolted-on
excrescence, hampering future maintenance.
--
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] tainted data issues

[Gregory Edigarov via Exim-users]

On 11/10/20 11:36 PM, Heiko Schlittermann via Exim-users wrote:

Hi,

I welcome the suggestions, especially the idea about gradually enabling
taintchecks, to allow a smooth transition, as suggested by Mike Tubby.

   taint_mode = yes | no | warn

Another idea from my side (it's similar to Sebastian N's idea)


   begin transports
 smtp:
   driver = smtp
   dkim_domain = $sender_address_domain
   dkim_selector = 2020-08-25
   dkim_private_key = /etc/exim/dkim/$dkim_selector.$dkim_domain.pem

We could provide taint checks for different situations, as the risk of
using tainted data depends on the usage of the data (filename, log
message, lookup key, …)

Provide a new set of functions:

 ${XXX{}{}{}}
 ${XXX{}{}fail}
 ${XXX{}{}}

With XXX as
 - file  (no "/")
 - path  (no "..")
 - line  (no "\r", "\n")
 ...

 dkim_private_key = 
/etc/exim/dkim/${file{$dkim_selector.$dkim_domain.pem}}
 or
 dkim_private_key = 
${path{/etc/exim/dkim/$dkim_selector.$dkim_domain.pem}}

This can give us flexibility where the current lookup based way of
untainting doesn't work.
I like the functions idea the best, as tainting is _already_ here, but 
really either way could do.




--
## 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] tainted data issues

[Sebastian Nielsen via Exim-users]

The thing is that I think that my idea with custom checker is better, since, it 
provides more flexibility, to configure it even stricter, for different use 
cases.

For what I know, the current risks that exist in a exim configuration when 
using user-supplied data is:

- Email redirection (fooling Exim into sending email as a open SMTP) - requires 
a "safe" localpart - and in some cases a safe "remote part"
- Writing outside intended locations
- Reading outside intended locations
- SQL injection
- Command injection in system commands
- Export to Web browser/HTML

Etc.
By making a custom possibility, with a select predefined "guranteed safe string 
sets", it will make exim more secure.
I think we should avoid creating lots of filter functions, when the filter 
could be specified using one of the predetemited filters, or a custom charset.


One example that would be useful for me would be like
${untaint(${localpart},"0123456789")
For my Email-to-SMS gateway.


Note that today its pretty complicated to filter data as "you want" - you need 
to write a regexp and do search/replace. It would be much better if a general 
filter/untaint function could be implemented, so it become easy-as-ass to 
filter data - as I said, even in situations where you don't need untainted 
data, but still want to filter to make data safe.

-Ursprungligt meddelande-
Från: Heiko Schlittermann via Exim-users  
Skickat: den 10 november 2020 22:44
Till: exim-users@exim.org
Ämne: Re: [exim] tainted data issues

Hi,

I welcome the suggestions, especially the idea about gradually enabling 
taintchecks, to allow a smooth transition, as suggested by Mike Tubby.

  taint_mode = yes | no | warn

Another idea from my side (it's similar to Sebastian N's idea)

>   begin transports
> smtp:
>   driver = smtp
>   dkim_domain = $sender_address_domain
>   dkim_selector = 2020-08-25
>   dkim_private_key = 
> /etc/exim/dkim/$dkim_selector.$dkim_domain.pem

We could provide taint checks for different situations, as the risk of using 
tainted data depends on the usage of the data (filename, log message, lookup 
key, …)

Provide a new set of functions:

${XXX{}{}{}}
${XXX{}{}fail}
${XXX{}{}}

With XXX as
- file  (no "/")
- path  (no "..")
- line  (no "\r", "\n")
...

dkim_private_key = 
/etc/exim/dkim/${file{$dkim_selector.$dkim_domain.pem}}
or
dkim_private_key = 
${path{/etc/exim/dkim/$dkim_selector.$dkim_domain.pem}}

This can give us flexibility where the current lookup based way of untainting 
doesn't work.


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -  Heiko 
Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -  gnupg 
encrypted messages are welcome --- key ID: F69376CE -



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
## 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] tainted data issues

[Heiko Schlittermann via Exim-users]

Hi,

I welcome the suggestions, especially the idea about gradually enabling
taintchecks, to allow a smooth transition, as suggested by Mike Tubby.

  taint_mode = yes | no | warn

Another idea from my side (it's similar to Sebastian N's idea)

>   begin transports
> smtp:
>   driver = smtp
>   dkim_domain = $sender_address_domain
>   dkim_selector = 2020-08-25
>   dkim_private_key = /etc/exim/dkim/$dkim_selector.$dkim_domain.pem

We could provide taint checks for different situations, as the risk of
using tainted data depends on the usage of the data (filename, log
message, lookup key, …)

Provide a new set of functions:

${XXX{}{}{}}
${XXX{}{}fail}
${XXX{}{}}

With XXX as
- file  (no "/")
- path  (no "..")
- line  (no "\r", "\n")
...

dkim_private_key = 
/etc/exim/dkim/${file{$dkim_selector.$dkim_domain.pem}}
or
dkim_private_key = 
${path{/etc/exim/dkim/$dkim_selector.$dkim_domain.pem}}

This can give us flexibility where the current lookup based way of
untainting doesn't work.


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
-- 
## 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] tainted data issues

[Sebastian Nielsen via Exim-users]

I think as I said, provide a untaint tool, that allows custom data to verify
against.

Like:
${untaint(${var},
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789")}

Regardless of if ${var} is tained or not, the result of ${untaint} is always
untainted.

The character string, is then what to filter against - all characters not on
that particular list, will be removed from ${var} silently before passing it
on.

This allows system administrators, to do entirely custom checks against
dangerous data, since in all cases where tainted data becomes a security
issue, is when delimiter characters is inserted in the text to escape out of
the enviroment that the command or whatever is executed in, and be able to
execute arbitary commands or write in arbitary locations.

Its very important that the function itself is "safe" - meaning it should
not be possible in ANY way for tainted data to "leak through" the filter,
ergo it must not be possible for any character not on administrator's list,
to end up in the return of the untaint function.

Also the filter list itself, must also be done in such a way variable
expansion never happens in the filter list - only way to specify a filter
list, is to manually specify it in config file.


This gives most flexibility, and also encourages security by making it easy
to filter data before passing it on, making it a "habit" for system
administrators.
Then it will be a habit to always ${untaint} even in cases where untainted
data is not required, incresing security even further.

In the above example, if ${var} contains
"Sebastian/Users/f...@somewhere.com" the result of the untaint operation
with that particular filter list would be "SebastianUsersfilesomewherecom"
which is a completely safe string to pass on to filesystem.

To make it even easier for system administrators, make premade filter lists
like:
%%FILESYSTEM%% = Contains a list of characters that is safe for use in
functions that read or write to filesystem.
%%SYSTEM%% = Containst a list of charactes that is safe to pass on to a live
terminal, like when running system commands or similiar.
%%SQL%% = Contains a list of characters that is safe to pass on to a raw SQL
prompt without rsik of injection.
%%HTML%% = Contains a list of characters that is safe to output to a web
browser without security risks.
%%LOCALPART%% = Contains a list of characters safe in localpart of a email
adress.
%%HOSTPART%% = Contains a list of characters safe to use in a DNS name or
host part of a adress including IP literals.
%%FULLEMAIL%% = Contains a list of characters that is allowed and safe to
use in a full email adress.

So writing:
${untaint(${var}, "%%SQL%%")}

Would filter ${var} in such a way that its safe to pass on to a raw SQL
string without injection risk.

Note that these %% strings is NOT string expansions - instead a customized
system for specifying pre-made filters, preventing variables from being
accidentially expanded and used in a filter list, which in itself is a big
security risk, since then filter lists could be modifyed from the outside.

However, \xXX should be expanded of course, so people can write characters
that don't exist on the keyboard, in some cases they are useful.


Such a untaint function should be easy to implement.
And would make exim much more secure, as its a very easy function, making it
a habit to use the function by system administrators.

YES - it is possible to "shoot yourself in the foot" with the function by
specofying characters that is unsafe for that particular usage, but then the
responsibility is on the system administrator.


Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: Michael Haardt via Exim-users  
Skickat: den 10 november 2020 20:16
Till: Jeremy Harris via Exim-users 
Ämne: Re: [exim] tainted data issues

Jeremy Harris via Exim-users  wrote:
> The one major hole I know of is for the creation of a mailbox file, 
> first time, for an account.

After having reviewed a number of configurations, I am sure there is more.

While I am not pleased with the design of verifying tainted data, or
introducing it in such an invasive manner without a new major version, the
need of doing so absolutely exists.  That said, the current design is usable
and it solves the problem.  Using it may either convince us of being the
best solution, or show which specific alternative is better.

The ongoing configuration reviews certainly uncovered potential problems, so
rolling back is not an option without a replacement for the current
verification.

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/



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
## 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] tainted data issues

[Gregory Edigarov via Exim-users]

On 11/10/20 10:37 AM, Julian Bradfield via Exim-users wrote:

I thought it was standard practice in introducing a new feature that
causes major breakage to existing installations, to take a three step
approach. First you provide the feature, and give it an enabling
switch with three levels "off", "warn but don't error", "on".
Then in successive releases you change the default value of the
enabling switch, and ultimately you remove the enabling switch.

I understand that taint protection is considered a security feature,
but it's a feature exim users have done without for decades, so I
can't really see that there was a particularly urgent need to
introduce it in a big bang.

not to say that it was done in incompatible manner,
breaking all configs that was working for years,
and with no way to switch to an old behaviour.

--
## 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] tainted data issues

[Jeremy Harris via Exim-users]

On 10/11/2020 06:44, Kai Bojens via Exim-users wrote:
The only problem I have with tainting is the lack of documentation. Why 
is there no single page with just "Hey, external data is now considered 
tainted.


To help the discussion along I've put up a copy of the current
(git HEAD) documentation.  It has moved on a little from the
4.94 release - in particular there is more indexing of
de-tainting methods.


https://people.exim.org/jeremy.harris/docs/HEAD/exim-html-4.94-RC999/exim-html-current/doc/html/spec_html/


The bit corresponding to Kai's request is about three sentences, near
the top of the String Expansions chapter.  Perhaps I'm too close to
the subject, but I can't see it taking a whole page.

--
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] tainted data issues

[Chris Siebenmann via Exim-users]

> We understand that this introduces an additional level of complexity
> for the configuration. And we're seeking for better ways, to balance
> between a secure and a simple configuration.
>
> We're open for suggestions. And intentionally we do not provide
> suggestions from our side here and now (this doesn't mean that we do
> not have ideas ;)) My thoughts I'll present here later.

 Here are some suggestions, ranging from moderate to radical.

 Moderate: there should be a full chapter in the Exim documentation on
tainting and how to deal with it. This should cover the security risks
that it's there to deal with, common configuration snippets that are now
a problem, and how to deal with tainting and de-tainting data in common
configuration needs. Right now there is not even an explicit subsection
for tainting in the Security Considerations chapter.

(If in the process of writing this chapter things are difficult to
explain or the configuration changes seem awkward, well, that is a
sign of where improvements are needed.)

 Semi-radical: there should be a configuration file option that turns
taint errors into warnings that do not stop processing but that are
merely logged to the main log or perhaps also the paniclog. Many system
administrators have existing Exim configurations that likely have
tainting problems, and we have no assurance that we can find them all
in advance of a live deployment. Live deployment with tainting creating
hard failures is a serious land mine and problem.

(It would be nice if all system administrators had automated test
suites that completely cover their entire Exim configuration. If people
think that having such a test suite should be required for reliable
Exim version upgrades, perhaps someone should write a chapter for the
Exim documentation on how to create and operate it, and also how to
measure the configuration file coverage so that you know you have 100%
coverage.)

 An optional but nice extra would be a third choice for this option,
which generates 'this would have been rejected' warnings if the contents
of the tainted variable being used seem harmless, but force hard errors
if it appears to have dangerous contents (whatever the Exim developers
consider that to be). That would be potentially somewhat safer than
running with the 'just always produce warnings and no more' option, but
might invite people to use this option permanently instead of upgrading
their configuration.

 Semi-radical: provide an ACL, router, and transport modifier that
checks some variable or content for dangerous contents (possibly in
several variations), and either passes it or triggers a condition
failure or deferral. Possibly this should be implemented as a function
that can be used in 'condition = ...' and '${if ...}' clauses, but if so
care should be taken to allow for a 'defer' result, not just pass/fail.
This would provide more assurances to sysadmins who are writing more
dynamic configurations that they haven't let something slip through in
their process for de-tainting variables through database queries or
whatever.

 People will inevitably wind up wanting to check various pieces of data
for 'bad stuff' and then de-taint them if there isn't any (or reject
them if there is), so the only question is whether Exim will provide
an official best effort at this (one that can be evolved over time
and perhaps have options for what sort of dangerous thing should be
accepted), or whether it will leave people writing configuration files
on their own to write hundreds of different and likely inferior and
flawed versions.

(Frankly, we would probably use it early in our ACLs too even though
we have hard-coded lists of valid recipients and so on, just so that
we can log messages if some attacker is trying to feed us dangerous
stuff.)

 Radical: $local_part, $domain, and similar tainted variables should
be automatically un-tainted once they pass a check that would generate
the untainted version of the variable. Forcing system administrators
to switch which variable they use has two problems. First, it is
make-work, since the two variables are essentially bolted together
(and if they are not, it is likely to surprise people, for example if
you somehow get $local_part changed but $local_part_data stays with
an old value). Second, it is part of what makes it impossible to have
a configuration file that works in both an old un-tainted Exim and
a new tainting Exim, since $local_part_data does not exist in older
Exims. Forcing configuration file updates at the same time as Exim
version updates complicates sysadmin life.

 Radical: in ACLs, verifying the receiver or sender address through
'verify = ' should optionally un-taint $local_part, $domain,
and so on. This should be controlled through a new option that has to
be turned on. In many configurations, verifying at least recipient
addresses will automatically restrict them to a list of known good
domains, local parts, and so on. Forcing ACLs to additionally 

Re: [exim] tainted data issues

[Michael Haardt via Exim-users]

Jeremy Harris via Exim-users  wrote:
> The one major hole I know of is for the creation of a
> mailbox file, first time, for an account.

After having reviewed a number of configurations, I am sure there is more.

While I am not pleased with the design of verifying tainted data, or
introducing it in such an invasive manner without a new major version,
the need of doing so absolutely exists.  That said, the current design
is usable and it solves the problem.  Using it may either convince us
of being the best solution, or show which specific alternative is better.

The ongoing configuration reviews certainly uncovered potential problems,
so rolling back is not an option without a replacement for the current
verification.

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] tainted data issues

[Jeremy Harris via Exim-users]

On 09/11/2020 22:27, Heiko Schlittermann via Exim-users wrote:

We're open for suggestions.


The one major hole I know of is for the creation of a
mailbox file, first time, for an account.

To that end I'm intending an enhancement of the "create_file"
option on the appendfile transport.  The implementation of
this is ready and waiting on the outcome of this discussion.
--
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] tainted data issues

[Andreas via Exim-users]

Am 10.11.2020 um 10:33 schrieb Mike Tubby via Exim-users:
> 
> 
> On 10/11/2020 08:37, Julian Bradfield via Exim-users wrote:
>> I thought it was standard practice in introducing a new feature that
>> causes major breakage to existing installations, to take a three step
>> approach. First you provide the feature, and give it an enabling
>> switch with three levels "off", "warn but don't error", "on".
>> Then in successive releases you change the default value of the
>> enabling switch, and ultimately you remove the enabling switch.
>>
>> I understand that taint protection is considered a security feature,
>> but it's a feature exim users have done without for decades, so I
>> can't really see that there was a particularly urgent need to
>> introduce it in a big bang.
>>
> 
> In one word "upvote".
> 
> I am all for improved security but a single "step change" that breaks
> existing configurations is IMHO going too far.
> 
>     taint_mode = off | warn | enforce
> 
> Would have been nice ;-)
> 
> 
> Mike
> 
> 
> 
Or in two words "upvote too".

I think "do or die" never is best practice.

If the next dist-upgrades breaks all of our exim installations all
updgrades had to be done by some "specialists" and and our normal
technicians can't do it during the normal update process without
breaking the whole service.

An exim switch like "test config for security" to check working
configurations for security issues would be nice. Like the "warn" from
above. And if all is good enforce as above. Well, above is nice! :)

And for the files, I really appreciate all your hard and good work and I
really love exim for the freedom to configure it in the way we need it ;)

Andreas


-- 
## 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] tainted data issues

[Mike Tubby via Exim-users]

On 10/11/2020 08:37, Julian Bradfield via Exim-users wrote:

I thought it was standard practice in introducing a new feature that
causes major breakage to existing installations, to take a three step
approach. First you provide the feature, and give it an enabling
switch with three levels "off", "warn but don't error", "on".
Then in successive releases you change the default value of the
enabling switch, and ultimately you remove the enabling switch.

I understand that taint protection is considered a security feature,
but it's a feature exim users have done without for decades, so I
can't really see that there was a particularly urgent need to
introduce it in a big bang.



In one word "upvote".

I am all for improved security but a single "step change" that breaks 
existing configurations is IMHO going too far.


    taint_mode = off | warn | enforce

Would have been nice ;-)


Mike



--
## 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] tainted data issues

[Kai Bojens via Exim-users]

Am 10.11.20 um 09:37 schrieb Julian Bradfield via Exim-users:


I understand that taint protection is considered a security feature,
but it's a feature exim users have done without for decades, so I
can't really see that there was a particularly urgent need to
introduce it in a big bang.



I'd like to disagree. In light of the recent 2019 RCE CVE's I really 
welcome these changes and think they are long overdue. There's just the 
point of a clear documentation which is missing IMHO.


--
## 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] tainted data issues

[Julian Bradfield via Exim-users]

I thought it was standard practice in introducing a new feature that
causes major breakage to existing installations, to take a three step
approach. First you provide the feature, and give it an enabling
switch with three levels "off", "warn but don't error", "on".
Then in successive releases you change the default value of the
enabling switch, and ultimately you remove the enabling switch.

I understand that taint protection is considered a security feature,
but it's a feature exim users have done without for decades, so I
can't really see that there was a particularly urgent need to
introduce it in a big bang.

-- 
## 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] tainted data issues

[Mark Elkins via Exim-users]

On 2020/11/10 08:44, Kai Bojens via Exim-users wrote:

Am 09.11.20 um 23:27 schrieb Heiko Schlittermann via Exim-users:



We're open for suggestions. And intentionally we do not provide
suggestions from our side here and now (this doesn't mean that we do 
not have

ideas ;)) My thoughts I'll present here later.


The only problem I have with tainting is the lack of documentation. 
Why is there no single page with just "Hey, external data is now 
considered tainted. This is how you handle this new stuff:"?


Right now the information about tainting is spread all over the 
documentation so that admins who upgrade have to go through all of this.


...and because of this, I have kept to older versions of EXIM - because 
my configs rely on the fact that all my users are in a MySQL Database.


Some more general "this is how you do it" examples would be greatly 
appreciated.

Thank you Heiko for raising this discussion.

I personally run some 1000 domains with perhaps 4000 e-mail users. Not 
big but not insignificant. I understand that when an email arrives, the 
recipient may not exist - but then the first thing I think I do is see 
if the address exists - and has not been suspended - etc. Surely this 
would cover 'tainted' data checks? Same for mail submission senders, 
they only 'get in' if their username (full email address) and password 
is a valid combination - so what is left to check?


As an aside, I also discovered my MySQL database was running on very old 
software - so there are other issues at hand too - just to confuse my 
particular issues. The old MySQL has just been sorted - so 'tainted' 
data is next.


Running an email service used to be reasonably easy... now people do 
dumb thinks like double SPF records or double sign DKIM (with one always 
broken).


So a suggestion, if its the incoming email that has tainted data - then 
an immediate lookup (give various examples) that then set some globally 
useable variables for everything else - could be an ideal way forward.


--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 




--
## 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] tainted data issues

[Kai Bojens via Exim-users]

Am 09.11.20 um 23:27 schrieb Heiko Schlittermann via Exim-users:



We're open for suggestions. And intentionally we do not provide
suggestions from our side here and now (this doesn't mean that we do not have
ideas ;)) My thoughts I'll present here later.


The only problem I have with tainting is the lack of documentation. Why 
is there no single page with just "Hey, external data is now considered 
tainted. This is how you handle this new stuff:"?


Right now the information about tainting is spread all over the 
documentation so that admins who upgrade have to go through all of this.


--
## 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/