A ‘critical’ security vulnerability has been discovered in the Exim mail server that requires admins’ urgent attention.
Affecting all versions from 4.80 up to and including 4.92.1, Exim’s maintainers have offered a general description of the flaw (CVE-2019-15846) discovered in July 2019 by a researcher identified as ‘Zerons’.
Subsequently confirmed by engineers working for Qualys, the flaw is a buffer overflow in the part of the TLS negotiation connected to Server Name Indication (SNI). SNI is a way web hosts present the certificates for multiple HTTPS-secured TLS servers sitting behind the same IP address so that incoming connections are directed to the correct one.
It’s as serious a flaw as it’s possible to imagine in a mail server because an attacker could exploit it either locally or from the internet with no special privileges by:
Sending an SNI ending in a backslash-null sequence during the initial TLS handshake.
Alternatively, attackers could attempt the same thing – achieving root on the target – using a crafted client TLS certificate.
Currently, there are no reported exploits for the flaw, which is believed to exist right now only as a proof of concept. Nevertheless:
If your Exim server accepts TLS connections, it is vulnerable. This does not depend on the TLS library, so both GnuTLS and OpenSSL are affected.
What to do
Exim is easily the most popular open-source mail server on the internet, accounting for almost 60% of those which are visible according to estimates.
An unwise few might not have TLS turned on but Exim admins are still advised to update to 4.92.2, which fixes the issue (disabling TLS resolves the problem but is not recommended).
Exim servers running versions prior to the vulnerability’s appearance in v4.80 (2012) are not at risk but will nevertheless be vulnerable to a number of others such as the CVE-2018-6789 remote code execution flaw from last year.
More recent Exim vulnerabilities include CVE-2019-10149 and a Linux worm later discovered by Microsoft to be targeting that flaw.
Note. The Sophos UTM and Sophos XG Firewall products use Exim, but strip out the SNI string before it gets to Exim so this bug can’t be triggered. (See Sophos Knowledge Base article 134597.) We’re going to apply the patch, but it will arrive in a scheduled maintenance release rather than as an ‘out-of-band’ emergency update.
Martin Feuerstein
Are the UTMs/XGs at risk?
Paul Ducklin
No. We strip out the SNI string before it gets to Exim so this bug can’t be triggered. More info:
https://community.sophos.com/kb/en-us/134597
We’re going to apply the patch, of course, but it will arrive in a scheduled maintenance release rather than as an ‘out-of-band’ emergency update.
HtH.
Martin Feuerstein
Thank you very much for the details! Why not include it in future news?
Paul Ducklin
The Knowledge Base Article article came out second so we didn’t have the link to send to the author :-) Actually, now you mention it, I’ll add it above as a sidebar for those who don’t see it down here in the comments (or who use some kind of comment blocker). To be fair to John, our articles are meant to be product agnostic anyway… but in this case it makes sense to add it.
Thanks for the comments.
Anon
So what is Sophos doing to mediate on their appliances?
Paul Ducklin
See the comment above – we don’t pass the SNI data to Exim so it never gets to the code with the bug in it. Patch to follow, because we can, but as part of a regular release rather than as a hotfix or out-of-band update.
HtH.