and I've belatedly noticed that this has already been posted by Marius,
sorry!
Apologies for the noise.
cheers,
calum.
On 23/06/2019 7:57 pm, Calum Mackay wrote: > Best I have so far is adding '$' to the the trailing case in the Debian
> default list of bad chars in local parts of local addresses:
>
> CHECK_RCPT_LOCAL_LOCALPARTS = ^[.] : ^.*[@%!/|`#&?] : ^.*\\\$
>
> which gets used here:
>
> deny
> domains = +local_domains
> local_parts = CHECK_RCPT_LOCAL_LOCALPARTS
> message = restricted characters in address
>
>
> I had to use '\\\$', rather than adding '$' to the existing [] block,
> due to both string expansion and '$' having a special meaning to PCRE.
>
>
> that seems to work, at least.
>
>
> This won't affect sender addresses with the exploit attempt, but those
> will just get delivered (assuming the recipient is good, with no frozen
> queue msgs.
>
> And it won't help for relaying attempts (where a '$' might in theory be
> valid), but my server should stop those before they get to the queue.
>
> Of course, this also required the patched exim to ensure the exploit
> doesn't actually work (with the sender address).
>
>
> comments?
>
> cheers,
> calum.
>
>
> On 23/06/2019 6:51 pm, Calum Mackay via Exim-users wrote:
>> On 22/06/2019 9:44 am, Andreas Metzler via Exim-users wrote:
>>> CVE-2019-10149 is not that it is possible to submit a mail that ends
>>> up frozen in the queue. CVE is a remote command execution
>>> vulnerabilty. The fix for CVE-2019-10149 does not remove the
>>> possibility to generate frozen mails in the queue, it stops the remote
>>> command execution.
>>
>> by any chance, please, would anyone happen to have an acl_smtp_rcpt
>> example that catches these particular exploit attempts — so my queue
>> doesn't fill up with these frozen msgs — /but/ still allows me to have
>> "user+suffix@domain" which I enable via local_part_suffix on a
>> redirect router?
>>
>> i.e. just rejecting '+' in the local part is too strict, here.
>>
>>
>> thanks very much indeed.
>>
>> cheers,
>> calum.
>>
