Second week of the fall provides us some unfortunate news.
Users are hit with an announcement of yet another Exim vulnerability. This is the second major occurrence that put the spotlight on Exim in less than three months. We already reported “The Return of the WIZard” aka CVE-2019-10149, and now we have CVE-2019-15846.
Why is this still a problem?
Exim is the most prevalent transfer agent that runs in the background of email servers. As you may know, email servers are not limited only to sending and receiving messages, they also play the role of relays for other emails.
The Nitty-Gritty Of The Newest Exim CVE
So what’s new?
Not much, the newer vulnerability still grants attacker root access, putting millions of servers in danger. Everyone who’s running on 4.92.1 version or earlier is, in fact, vulnerable.
To be more precise, there are 5.2 million Exim servers falling into the “vulnerable” category, and they are easily exploited.
Here is what we know about this vulnerability from online sources:
- The vulnerability is exploitable by sending a SNI ending in a backslash-null sequence during the initial TLS handshake
- This vulnerability allows an attacker to take advantage of the TLS ServerName Indicator, a feature that allows TLS to serve different certificates for various websites.
- The vulnerability doesn’t depend on the TLS library being used by the server, both GnuTLS and OpenSSL are affected.
The timeline says we have a lifeline, but why drown in the first place?
2019-07-21 – Report from Zerons to security@exim.org, analysis by Qualys, fix and tests
2019-09-02 – CVE assigned
2019-09-03 – Details to distros@vs.openwall.org, exim-maintainers@exim.org
2019-09-04 – Heads-Up to oss-security@lists.openwall.com, exim-users@exim.org
2019-09-06 – 10.00 UTC Coordinated Release Date. Disclosure to oss-security, exim-users, public repositories
The issue has been patched since in utmost secrecy, and that is okay for a couple of different reasons..Return of the WIZard came under active exploitation within a week after public disclosure, so we still have some sand in our clock.
Although there is no public exploit code for this vulnerability yet, it’s creation is only a question of time.
Time To Act Now, There’s No Need To Wait For Us
There are two ways to mitigate the problem, one of which is reactive, and the other carries another, even bigger risk.
The first option is of course to patch, nothing surprising here. The second option is a lot more question-raising, and it involves users disabling TLS support for Exim server.
Please do not attempt to proceed with the second option, as that will put all your email traffic in clear text, and set you up for even more problems. GDPR fines will come in a rapid fury if such a method will be used by an EU living user, as it will likely increase the risk of data leaks.
Time is on your side for now, but there’s another way to deal with such threats, and that’s to step away from the Mail Transfer Agents altogether.
If I was forced to choose between those options I would certainly pick updating.
But luckily, I don’t have to bother about this problem as much, because I am not sticking to message transferring through Simple Mail Transfer Protocol (SMTP), that doesn’t have any real security model in its repertoire.
If you would like to have complete control over your email communication, then go to StealthMail.com and find out more about the patented SDNP-based solution that never exposes your data to the public Internet.
Link copied to clipboard!