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. Br
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
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:
>>>
>
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 opt
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
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
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
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 thi
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
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
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
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
--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 thes
lkins 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'
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 r
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 shorth
-
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 reviewe
>>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 saf
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 dangerou
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 "t
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
> c
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 th
> 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.
Hi
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
@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},>
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz012
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
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 t
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 remov
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 Sebas
er 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 sim
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
ers 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
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
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
> 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 (
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 i
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 impl
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 pro
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",
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 li
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 c
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 pres
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 i
Hello,
As many of you may have noticed, with the release of 4.94 we introduced
strict checks for the data Exim uses in expansions. This broke old
configurations that used "tainted" data.
Unfortunately the introduction of these taint checks wasn't communicated
very well, and as not all of you were
44 matches
Mail list logo
