Re: filter oddities

2020-01-29 Thread Edgar Pettijohn




On 01/25/20 16:14, Edgar Pettijohn wrote:



On 01/25/20 14:48, Edgar Pettijohn wrote:



On 01/25/20 14:24, gil...@poolp.org wrote:
January 25, 2020 9:21 PM, "Edgar Pettijohn" 
 wrote:



On 01/25/20 14:20, gil...@poolp.org wrote:

January 25, 2020 8:50 PM, "Edgar Pettijohn" 
 wrote:


I haven't seen any mention of this, but for some reason in my 
limited "testing" of filters I have
to use \r\n in my responses to smtpd. Is this normal? Doesn't 
seem to be documented and what

filters I've looked at don't appear to be using \r\n.

Indeed, you must certainly NOT use "\r\n" in filters.

For example without ORS = "\r\n" the following script will cause 
smtpd to basically just hang.
There is no errors reported, but when I attempt to telnet 
localhost 25 the daemon doesn't greet me.

After adding ORS = "\r\n" everything works as expected.
I'm not familiar with awk beyond very basic uses, could this be 
due to some
flushing not happening by default and which gets triggere with 
"\r\n" ?

Adding:

setvbuf(stdout, NULL, _IONBUF, 0);

to awk's main() fixes it on my laptop. Still don't understand how my 
laptop is apparently the only device effected...


At least I can continue testing on my laptop anyway.

Edgar



Re: Interim mitigation for CVE-2020-7247

2020-01-29 Thread gilles
January 29, 2020 12:19 PM, "Andreas Broecking"  wrote:

> Hi all,
> 
> first of all, thanks Gilles for the heads-up and a fix on short notice.
> 
> For people like me who relay on the portable version and for systems which 
> relay on built packages
> as they lack the local development tools, a filter should help to mitigate 
> the problem until a
> package could be built on another system.
> 
> Shouldn’t something like 
> 
> filter exploit_check phase mail-from match mail-from regex { '<*\;*' } \
> disconnect "550 no exploiting, kthx”
> 
> listen on $interface filter exploit_check
> 
> sufficiently mitigate the problem?
> I am not fluent in regex’ing so maybe I am missing an edge case. It does 
> prevent the example
> exploit and any others I’ve seen in the last hours.
> 

filter exploit_check phase mail-from match mail-from regex ".*;.*" \
disconnect "550 no exploiting, kthx”

listen on $interface filter exploit_check

This should work yes but I don't have an unpatched system to test it.
You also need it on "listen on socket"

The best mitigation would be to use maildir instead of mbox as it's not 
impacted.



Re: Interim mitigation for CVE-2020-7247

2020-01-29 Thread Andreas Broecking
Or rather 

filter exploit_check phase mail-from match mail-from regex { '.*\;.*\;.*’ }
disconnect "550 no exploiting, kthx”

to be more specific on the semicolons as delimiter of the command?

(sorry, as I said. regex is my nemesis :))

Best regards
Andreas



> On 29. Jan 2020, at 12:19, Andreas Broecking  wrote:
> 
> Hi all,
> 
> first of all, thanks Gilles for the heads-up and a fix on short notice.
> 
> For people like me who relay on the portable version and for systems which 
> relay on built packages as they lack the local development tools, a filter 
> should help to mitigate the problem until a package could be built on another 
> system.
> 
> Shouldn’t something like 
> 
> filter exploit_check phase mail-from match mail-from regex {  '<*\;*' } \
>disconnect "550 no exploiting, kthx”
> 
> listen on $interface filter exploit_check
> 
> sufficiently mitigate the problem?
> I am not fluent in regex’ing so maybe I am missing an edge case. It does 
> prevent the example exploit and any others I’ve seen in the last hours.
> 
> Best regards
> Andreas




Interim mitigation for CVE-2020-7247

2020-01-29 Thread Andreas Broecking
Hi all,

first of all, thanks Gilles for the heads-up and a fix on short notice.

For people like me who relay on the portable version and for systems which 
relay on built packages as they lack the local development tools, a filter 
should help to mitigate the problem until a package could be built on another 
system.

Shouldn’t something like 

filter exploit_check phase mail-from match mail-from regex {  '<*\;*' } \
disconnect "550 no exploiting, kthx”

listen on $interface filter exploit_check

sufficiently mitigate the problem?
I am not fluent in regex’ing so maybe I am missing an edge case. It does 
prevent the example exploit and any others I’ve seen in the last hours.

Best regards
Andreas


Re: OpenSMTPD 6.6.2p1 released: addresses CRITICAL vulnerability

2020-01-29 Thread Harald Dunkel

Hi Gilles,

On 2020-01-28 23:30, gil...@poolp.org wrote:

Hello misc@,

Qualys has found a critical vulnerability leading to a possible privilege 
escalation.

It is very important that you upgrade your setups AS SOON AS POSSIBLE.

We'll provide more details when the advisory will be out and I'll take time to 
write
about how this bug was made possible, but in the meantime get your setups fixed 
!



Which versions of opensmtpd are affected?

Thanx for the quick fix.
Harri



Re: OpenSMTPD 6.6.2p1 released: addresses CRITICAL vulnerability

2020-01-29 Thread Reio Remma

On 29/01/2020 00:30, gil...@poolp.org wrote:

Hello misc@,

Qualys has found a critical vulnerability leading to a possible privilege 
escalation.

It is very important that you upgrade your setups AS SOON AS POSSIBLE.

We'll provide more details when the advisory will be out and I'll take time to 
write
about how this bug was made possible, but in the meantime get your setups fixed 
!



Thanks a lot for the heads up! Updated my CentOS 7 packages.

Thanks,
Reio