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.
>
