Re: filter oddities
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
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
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
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
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
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
