Ok, Exim 4.87 < 4.92 has a serious security hole, which can also be trivially exploited: CVE-2019-10149
A lot of fuss has been made about the weak point, but unfortunately nobody has been able to tell whether it can be fended off without an update. Let’s have a look at what it’s all about.
What is the trivial exploit?
As a local attacker it is enough to send an email with Exim’s sendmail replacement to „<${run{bash}}@zieldomain.de>“. At the moment it is delivered, the embedded command (here bash) is executed as root.
The whole thing can also be executed remotely, so it’s a really nasty vulnerability. But only versions > 4.87 < 4.92 are affected. For this, however, various things must be allowed in the config, which is only partially the case in the default configuration. For example, you cannot include a „/“ in the command because these are illegal characters. This of course restricts the attacker from being strong.
Since even on the exim list there was a lot of secrecy in the game until today, here are the equally trivial countermeasures:
Countermeasures
Just don’t allow „$“ in email addresses đ That’s it. There only ARGS came to my mind đ
This comes into your Exim configuration, then restart Exim:
acl_check_rcpt:
deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[\$@%!/|]deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[\$@%!] : ^.*/\\.\\./âŠ.
acl_check_mail:
âŠ
drop message = Restricted characters in address
condition = ${if match{$sender_address}{\N.*\$.*run.*\N}{1}{0}}}# IMPORTANT: Write in before these instructions, otherwise it’s not working!
accept hosts = +relay_from_hosts
…
This chokes off the attacker before the email is delivered.
The better countermeasure would of course be to switch to a more recent Exim. But as it is, there are always „reasons“ why and why something can’t be updated.
Nobody gets his teeth apart…
What annoys me most of all about the gap is that this cheap countermeasure does not appear in the Advisory of Qualys and in the hints of the Exim Team. With the Exim people I can still understand it, because they had fixed the bug independently already at the beginning of the year and can say justly: Just do updates.
Qualyss looks different, they write :
As per the distros list policy:
Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.We believe that it makes no sense to delay this any longer than that:
this vulnerability is trivially exploitable in the local and non-default
cases (attackers will have working exploits before that, public or not);
and in the default case, a remote attack takes a long time to succeed
(to the best of our knowledge).
Nice that you omitted the exploit, how about the workaround, so that the good guys have a small lead? And this cryptic hint „a remote attack takes a long time to succeed“ means that you should restart your exim every 24h, because there is some shit with „tar pits“.
These are usually spam traps that respond so slowly that the attacker’s attack is just as tough as in a tar pit, up to „no progress at all“. The attackers take advantage of something like this here. Therefore once in the cron „killall -9 exim; systemctl restart exim“ daily : Done.
A follow-up of the aftermatch and some real exploits can be found here: Exim – Exploit in der Wildnis unterwegs
Translated with www.DeepL.com/Translator
BTW: yes, ofcourse i could have written it in english myself, but the translation isn’t that bad đ
