Re: [exim] Taint checking and exim 4.96rc0

2022-04-29 Thread Slavko (tblt) via Exim-users
Dňa 29. apríla 2022 21:41:55 UTC používateľ Kirill Miazine via Exim-users 
 napísal:

>I'd welcome some generic way to untaint data. E.g. Perl would allow to
>subpatterns from regular expression match to untaint parts of data. For
>local parts and domains there's kind of a way, but for local part
>affixes or sender addresses, I couldn't find a way.

Yes, as i wrote the same already some time ago, some generic
${detaint:...} expansion is missing. All current solutions are based
on "local" DB lookup. But it is not suitable e.g. to my case, where i
verify recipients from my MX to my other MTA (where local DB are
stored) by callout. But that doey not detaint recipient address nor
domain, thus i have to use some tricks to be able to use per
recipient/domain (something as) quarantine on MX...

As redis support is not full (and on Debian is missing at all) i use
${run ...} to communicate with redis and i afraid, that i will have
problems to use it in new version, etc, etc. I have very mixed feel.
And i can only afraid, what will arrive next. Perhaps reject to detaint
by that local DB values (as someone can insert insecure values
there)?

After more than 30 years in computer & network word i learn, that
software can either allow to do flexible configuration (including
mistakes) or do not allow to do mistakes (but without flexibility),
never can be achieved both at once... Until recent, exim was in the
first case and we will see, where it go.

Regards

-- 
Slavko

-- 
## 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] Taint checking and exim 4.96rc0

2022-04-29 Thread Jeremy Harris via Exim-users

On 29/04/2022 22:41, Kirill Miazine via Exim-users wrote:

I'd welcome some generic way to untaint data.


If you know of one which does not require a list
of known-good values, and is not trivially abusable
by blind copy-pasting of recipes found on random blogs -
I'm all ears.
--
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] Taint checking and exim 4.96rc0

2022-04-29 Thread Kirill Miazine via Exim-users
• Heiko Schlittermann via Exim-users [2022-04-29 21:07]:
[...]
> The "allow_insecure_tainted_data" was introduced to ease the migration
> from 4.94 to 4.95, giving you/us a timeframe to upgrade existing
> configurations to be taintproof.
> 
> Before upgrading to 4.96 you should have a taintproof (secure)
> configuration. The deprecation of "allow_insecure_tainted_data" was
> announced with the advent of this option already.
> 
> Which point did I miss? Do we have *new* taintchecks that break
> configurations that were considered secure with 4.95?

I had a setup which didn't use allow_insecure_tainted_data, but I was
hit by

JH/25 Taint-check exec arguments for transport-initiated external processes.
  Previously, tainted values could be used. This affects "pipe", "lmtp" and
  "queryprogram" transport, transport-filter, and ETRN commands.
  The ${run} expansion is also affected: in "preexpand" mode no part of
  the command line may be tainted, in default mode the executable name
  may not be tainted.

I welcome taint checking facilities, but I'm afraid that the
introduction of taint checking for exec arguments will cause lots of
broken configurations. Even the Exim spec has (had) examples which would
be broken by the change. When shell is not used, the only reason for
tain checking argument would be to protect the command being called in
case it's not prepared to deal with malicious arguments.

When using Perl's taint checking facilities (-T) some 20 years ago,
I remember I spent quite a while reading perlsec(1). Memories from that
time helped me when trying to understand taint checking in Exim. The
Exim documentation is still not very detailed about the concept. I'm not
ready to write anything, as I haven't gained enough understanding myself
yet.

I'd welcome some generic way to untaint data. E.g. Perl would allow to
subpatterns from regular expression match to untaint parts of data. For
local parts and domains there's kind of a way, but for local part
affixes or sender addresses, I couldn't find a way.

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

-- 
-- Kirill Miazine 

-- 
## 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] Taint checking and exim 4.96rc0

2022-04-29 Thread Michael Haardt via Exim-users
Dean Brooks via Exim-users  wrote:

> On Fri, Apr 29, 2022 at 05:16:45PM +0100, Andrew C Aitchison via Exim-users 
> wrote:
> 
> > Given that taint checking appeared in Exim 4.93 and
> > allow_insecure_tainted_data in Exim 4.95,
> > this (Exim 4.96) would be the first time that allow_insecure_tainted_data
> > would actually be helpful.
> > 
> > Is it just me, or are others worried about the new taint checking
> > having unexpected consequences and no way to disable it for debugging ?
> 
> I'd prefer the allow_insecure_tainted_data never be removed, now or in the 
> future. At the least, as an experimental feature that requires intentional 
> enabling during a source build. At the worst as a separate community 
> maintained patch against the official source for each new release. 
> Maintaining production mail systems that handle millions of messages a month 
> is no trivial feat, and a single taint failure can turn (and has turned) a 
> routine upgrade plan into a mess.

100% agreement. Having to include it as build option is reasonable.

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] Taint checking and exim 4.96rc0

2022-04-29 Thread Heiko Schlittermann via Exim-users
Andrew C Aitchison via Exim-users  (Fr 29 Apr 2022 
18:16:45 CEST):
> To which Jeremy replied:
> > The trouble with that is that it means the coverage of tracking
> > tainted data use can never be extended.
> > 
> > The commit for that removal is fairly extensive:
> - see https://lists.exim.org/lurker/message/20220427.174941.443df2eb.en.html
> for the 27 reverts and 35 files changed.
> 
> Given that taint checking appeared in Exim 4.93 and
> allow_insecure_tainted_data in Exim 4.95,
> this (Exim 4.96) would be the first time that allow_insecure_tainted_data
> would actually be helpful.
> 
> Is it just me, or are others worried about the new taint checking
> having unexpected consequences and no way to disable it for debugging ?

The "allow_insecure_tainted_data" was introduced to ease the migration
from 4.94 to 4.95, giving you/us a timeframe to upgrade existing
configurations to be taintproof.

Before upgrading to 4.96 you should have a taintproof (secure)
configuration. The deprecation of "allow_insecure_tainted_data" was
announced with the advent of this option already.

Which point did I miss? Do we have *new* taintchecks that break
configurations that were considered secure with 4.95?

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] Taint checking and exim 4.96rc0

2022-04-29 Thread Dean Brooks via Exim-users
On Fri, Apr 29, 2022 at 05:16:45PM +0100, Andrew C Aitchison via Exim-users 
wrote:

> Given that taint checking appeared in Exim 4.93 and
> allow_insecure_tainted_data in Exim 4.95,
> this (Exim 4.96) would be the first time that allow_insecure_tainted_data
> would actually be helpful.
> 
> Is it just me, or are others worried about the new taint checking
> having unexpected consequences and no way to disable it for debugging ?

I'd prefer the allow_insecure_tainted_data never be removed, now or in the 
future. At the least, as an experimental feature that requires intentional 
enabling during a source build. At the worst as a separate community maintained 
patch against the official source for each new release. Maintaining production 
mail systems that handle millions of messages a month is no trivial feat, and a 
single taint failure can turn (and has turned) a routine upgrade plan into a 
mess.

Thanks,
Dean

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


[exim] Taint checking and exim 4.96rc0

2022-04-29 Thread Andrew C Aitchison via Exim-users



On Mon, 25 Apr 2022, Kirill Miazine via Exim-dev wrote:

Beware that the just released RC0 for Exim 4.96 may break your Dovecot
LDA delivery. It did break mine, which is similar to what is described
on https://wiki.dovecot.org/LDA/Exim

Here is the relevant ChangeLog entry:

JH/25 Taint-check exec arguments for transport-initiated external processes.
 Previously, tainted values could be used.  This affects "pipe", "lmtp" and
 "queryprogram" transport, transport-filter, and ETRN commands.
 The ${run} expansion is also affected: in "preexpand" mode no part of
 the command line may be tainted, in default mode the executable name
 may not be tainted.



 Jeremy Harris via Exim-announce [2022-04-23 20:23]:
> Notable removals since 4.95:
>
>   - the "allow_insecure_tainted_data" main config option and the
> "taint" log_selector.  These were previously deprecated.


That seemed like an unfortunate combination to me, so over on the
exim-dev list
https://lists.exim.org/lurker/message/20220426.072833.c68602fb.en.html
I asked:

That isn't a good combination. Please could we keep the option to
allow_insecure_tainted_data if there are new taint features ?

That way we can continue to run live systems while we resolve
these sort of problems.


To which Jeremy replied:

The trouble with that is that it means the coverage of tracking
tainted data use can never be extended.

The commit for that removal is fairly extensive:
- see 
https://lists.exim.org/lurker/message/20220427.174941.443df2eb.en.html

for the 27 reverts and 35 files changed.

Given that taint checking appeared in Exim 4.93 
and allow_insecure_tainted_data in Exim 4.95,

this (Exim 4.96) would be the first time that allow_insecure_tainted_data
would actually be helpful.

Is it just me, or are others worried about the new taint checking
having unexpected consequences and no way to disable it for debugging ?

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