Mandi! Dmitriy Matrosov via Exim-users
In chel di` si favelave...
> (Debian 6, 4.72, no $tls_sni, no $tls_in_sni)
4.72 is not vulnerable, as Heiko say in:
https://www.bleepingcomputer.com/news/security/critical-exim-tls-flaw-lets-attackers-remotely-execute-commands-as-root/
--
Tut
On 9/9/2019 7:16 AM, Jan Ingvoldstad via Exim-users wrote:
I've had another variant for years:
acl_check_mail:
deny
message = no HELO given before MAIL command
condition = ${if def:sender_helo_name {no}{yes}}
delay = 60s
The delay is a nice touch, if you have the TCP connectio
Hello Konstantin,
Please look at
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html
and look at the description after “
delay =
“
Jan
(Sorry for top posting, editing sucks on cell)
> 9. sep. 2019 kl. 16:37 skrev Konstantin Boyandin via Exim-users
> :
>
>
Hello Jan,
"delay" means tarpitting, in this context?
I wonder how efficient that is.
Sincerely,
Konstantin
On 09.09.2019 21:16, Jan Ingvoldstad via Exim-users wrote:
> I've had another variant for years:
>
> acl_check_mail:
> deny
> message = no HELO given before MAIL command
> cond
I've had another variant for years:
acl_check_mail:
deny
message = no HELO given before MAIL command
condition = ${if def:sender_helo_name {no}{yes}}
delay = 60s
The delay is a nice touch, if you have the TCP connections to spare.
Jan
On Mon, Sep 9, 2019 at 4:10 PM Phillip Carroll
my configuration has had something similar for years. Is there any
significant difference?
acl_check_mail:
# deny any mail without helo name
denymessage = HELO required before MAIL
condition = ${if eq{$sender_helo_name}{} {1}}
(Yours obviously simpler to read)
On 9/6/2019 6:1
Dmitriy Matrosov via Exim-users (Sa 07 Sep 2019 10:39:20
CEST):
> >
> > And, if your Exim is linked against GnuTLS there is no $tls_sni variable
> > at all. But - to my knowledge - the exploitable string is written to the
> > -H spool file anyway (and read back).
>
> On Debian 7, 8, 9 (exim is li
Am 07.09.19 um 03:16 schrieb Phil Pennock via Exim-users:
> On 2019-09-06 at 22:04 +0200, Heiko Schlittermann via Exim-users wrote:
>> The HELO ACL doesn't help either, as the first EHLO comes before
>> STARTTLS, and the second EHLO doesn't have to come, the client may send
> Oh pox. My memory is
On 9/7/19 9:51 AM, Heiko Schlittermann via Exim-users wrote:
Marco Gaiarin via Exim-users (Fr 06 Sep 2019 23:42:03
CEST):
Mandi! Heiko Schlittermann via Exim-users
In chel di` si favelave...
Add - as part of the mail ACL (the ACL referenced by the main config
option "acl_smtp_mail"):
Marco Gaiarin via Exim-users (Fr 06 Sep 2019 23:42:03
CEST):
> Mandi! Heiko Schlittermann via Exim-users
> In chel di` si favelave...
>
> > Add - as part of the mail ACL (the ACL referenced by the main config
> > option "acl_smtp_mail"):
> > denycondition = ${if eq{\\}{${substr{-1}{1}{
On 2019-09-06 at 22:04 +0200, Heiko Schlittermann via Exim-users wrote:
> The HELO ACL doesn't help either, as the first EHLO comes before
> STARTTLS, and the second EHLO doesn't have to come, the client may send
Oh pox. My memory is going. I hadn't realized that my protection
against this comes
Mandi! Heiko Schlittermann via Exim-users
In chel di` si favelave...
> Add - as part of the mail ACL (the ACL referenced by the main config
> option "acl_smtp_mail"):
> denycondition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni
> denycondition = ${if eq{\\}{${substr{-1}{1}{$tl
Sebastian Nielsen via Exim-users (Fr 06 Sep 2019 20:50:37
CEST):
> Shouldn't this be in connect ACL?
> How would the deny in MAIL FROM prevent the exploit? What I have understand
> is that there is exploit in the SNI of the TLS negotiation, thus the whole
> connect attempt must be rejected righ
Sebastian Nielsen via Exim-users (Fr 06 Sep 2019 21:37:41
CEST):
> Ooo just that, forgot that...
>
> But still the question remains, how does it prevent the exploit? Doesn't the
> exploit (root command) get executed immidiately when TLS negotiation is
> done?
This is left as an exercise to the r
19 21:35
Till: exim-users@exim.org
Ämne: Re: [exim] CVE-2019-15846: Exim - local or remote attacker can execute
programs with root privileges
Am 06.09.19 um 20:50 schrieb Sebastian Nielsen via Exim-users:
> Shouldn't this be in connect ACL?
> How would the deny in MAIL FROM prevent the
Am 06.09.19 um 20:50 schrieb Sebastian Nielsen via Exim-users:
> Shouldn't this be in connect ACL?
> How would the deny in MAIL FROM prevent the exploit? What I have understand
> is that there is exploit in the SNI of the TLS negotiation, thus the whole
> connect attempt must be rejected right?
>
Heiko
Schlittermann via Exim-users
Skickat: den 6 september 2019 13:22
Till: oss-security ; Exim Users
Ämne: Re: [exim] CVE-2019-15846: Exim - local or remote attacker can execute
programs with root privileges
An Update to the mitigation for the current CVE:
Add - as part of the mail ACL (the ACL refer
Am 06.09.19 um 13:14 schrieb Heiko Schlittermann via Exim-users:
> An Update to the mitigation for the current CVE:
>
> Add - as part of the mail ACL (the ACL referenced by the main config
> option "acl_smtp_mail"):
>
> denycondition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni
> den
CVE ID: CVE-2019-15846
Credits:Zerons , Qualys
Version(s): all versions up to and including 4.92.1
Issue: The SMTP Delivery process in all¹ versions up to and
including Exim 4.92.1 has a Buffer Overflow. In the default
runtime configuration, this is exploitable
An Update to the mitigation for the current CVE:
Add - as part of the mail ACL (the ACL referenced by the main config
option "acl_smtp_mail"):
denycondition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni
denycondition = ${if eq{\\}{${substr{-1}{1}{$tls_in_peerdn
This should
Heiko Schlittermann (Fr 06 Sep 2019 12:20:39
CEST):
> Mitigation
> ==
>
> Do not offer TLS for incomming connections (tls_advertise_hosts).
> This mitigation is *not* recommended!
This should block the most popular attack vector:
In your MAIL ACL:
denycondition = ${if eq{\\}{${
*** Note: EMBARGO is still in effect! ***
*** Distros must not publish any detail yet ***
In case you are entitled to access the security repo:
*and* use the 4.92.2+fixes branch:
The branch got two new commits, fixing a small tool. This tool is not
designed to process untrusted data, so the
*** Note: EMBARGO is still in effect! ***
*** Distros must not publish any detail yet ***
Head up! Security release ahead!
CVE ID: CVE-2019-15846
Version(s): up to and including 4.92.1
Issue: A local or remote attacker can execute programs with root
privileges.
Details:
23 matches
Mail list logo
