Exim is a mail transfer agent (MTA) used on Unix-like operating systems. [...] In August 2019 [...] approximately 57% of the publicly reachable mail-servers on the Internet ran Exim.
This is the entire web hosting industry. The attack surface is massive and the industry has been so squeezed of costs that patching stuff will take a long time. This exploit will be alive for a long long time.
To its credit, cPanel updates nightly and the developers will push security patches out within hours. I don’t have a box to check but I would imagine a cPanel patch is already live.
As stated in the initial bug report by Zerons, an unauthenticated remote attacker could send a malicious SNI ending in a backslash-null sequence during the initial TLS handshake, which causes a buffer overflow in the SMTP delivery process. This would allow an attacker to inject malicious code that Exim then arbitrarily executes as root. This vulnerability does not depend on the TLS library in use, so both GnuTLS and OpenSSL are affected.
Why is exim running as root at that point? At least that is the question in my mind. Once it has bound to the port it should setuid() or seteuid() to a less privileged UID, unless I'm mistaken.
Granted, there will still be the possibility of remote code execution as a non-root user, but at least you're not handing an attacker root privileges by default.
Exim can do a lot of things, including delivery of mail to users' directories. Root privileges are required to access those directories. Oh, also ".forward" files in users' home directories.
I guess this is why Ubuntu ships exim binary with setuid bit on it
Ugh, the deliver program should be a seperate process then with some sort of privilege seperation scheme perhaps. Postfix also handles .forward files from memory, I wonder how it does it.
Maybe the Exim people don't feel like its worthwhile to rearchitect it, given that there are MTA's with more secure designs/implementations out there already.
Maybe Exim people are smarter than you give them credit for. Exim does use separate processes and privilege separation.
SMTP daemon itself does not run as root (on default Debian it runs as "Debian-exim" user). Some processes do need to run as root for local delivery, as others have mentioned.
How exactly this exploit works around that I don't know. PoC isn't public. Bugs happen, even with secure designs.
Thanks for the information, I haven't used Exim since I last used Debian where it was the default MTA in the 1990's. I wasn't trying to imply that they weren't smart. If Ubuntu has it setuid root, than that's a different issue, although I still don't see why it wouldn't drop those privileges at the earliest opportunity.
Like any MTA it needs to be root to connect to port 25. It can and does drop privilege after that. Like any MTA it needs to have a process running as root to do local deliveries as a particular user and to do .forwards . It appears that process is what is being attacked here. If you don't do local deliveries/.forwards, you don't have to have any processes running as root.
It's worth noting that as far as I can tell, Linux didn't support CAP_NET_BIND_SERVICE until 2.6.24[1], which was released in January 2008[2].
Exim itself dates from 1995[3].
I'm not really up to date on the use of capabilities, but it would seem that it can be setup before running the main processes anyway[4] using the setcap command (not sure how portable this is on other platforms, eg. BSD's) and it would appear to be a distribution/packaging issue in that context anyway.
There is also always the possibility of setting the port used for SMTP connections to a port higher than 1024 anyway, and using iptables/firewalld etc. to forward port 25 to that unprivileged port, as also discussed in [4].
Of course, neither of these options help in the specific case of needing to access user's home directories, either to read .forward files or deliver mail there directly.
Indeed. qmail describes this quite well and is portable for unix. The qmail-queue process does local deliveries, tcpserver runs against port 25 and invokes qmail-smtpd. Spending time to design software into small components pays for itself in the long run. I think qmail's downfall was that it is so stable people dind't have many issues to fix once the patches were written. It is starting to reform in 'notqmail', which I'm hoping will spar with postfix.
Indeed, kind of the point I was making, maybe not clearly enough. I don't remember the last remote root exploit discovered for Postfix, or even if there ever was one.
Why does it even need to presumably parse escape sequences in an SNI? AFAIK that extension holds a hostname and nothing else, and is length-delimited anyway. I'd consider the buffer overflow merely a side-effect of what is really a fundamentally wrong design decision leading down a codepath that should've never been reached in the first place.
It doesn't, it serializes the SNI name by applying backslash escaping, but fails to escape the escape character, and then incorrectly parses that serialized form.
*(++p) --- what did you think it would do without the parentheses...?
isdigit(ch) && ch != '8' && ch != '9' --- why not the simpler ch >= '0' && ch <= '7' ?
That code reminds me of FizzBuzz and the huge gap in competence it demonstrates, i.e. a surprisingly large number of "programmers" fail to write correct solutions to the simplest of problems. Perhaps "unescape a string" needs to be an interview question with as much attention as FizzBuzz, both because it has a practical application and can show a lot about someone's skill. Admittedly, I may be biased because I have done a lot of parsing and other compiler-ish work, but parsing text is really not an uncommon thing to do in a lot of applications.
Yeah, pointer arithmetic with raw string handling is usually bad news bears. I wonder if it's possible to write a bot that grabs every "string.c" or "str.c" (etc.) from GitHub and looks for this stuff.
Being a monolith, it can do lots of really nasty things to spammers and that functionality is easy to set up due to the relative simplicity of the Exim configuration.
It also can do things that other MTAs can't do at all, again due to it being a monolith.
Postfix for example is made out of a string of independent programs that pass mail to one another. Once a program has an email that program can only deal with the email itself or pass it along to the next program. That limits what can be done with that email and makes the configuration harder to understand.
(I don't send e-mail to the outside or listen for any outside e-mail, so the choice of MTA is irrelevant to me as long as the system can still send over localhost to /var/mail/$USER.)
When it is the sole supported SMTP server for the most popular hosting panel, cPanel, it's going to be heavily used even if it was awful on all other fronts (and from other comments, it sounds to be pretty good... other than security, which is a big deal).
I use Postfix, which I believe has a pretty good (though not spotless) security track record. The most recent CVE for it seems to have been in 2017, and that was local privilege escalation.
Postfix is rock solid in my experience. And probably more flexible than people give it credit for. There’s a ton of configurability. I’ve used it for over a decade now and every issue I’ve run into has been my error or something else in the stack or path.
People usually don't choose it. It's the usual hosting providers mail service of choice, because it's so easy to configure for thousands of domains and users. Not just cPanel, almost everybody.
opensmptd (which seems a) to have a simple config and b) is a new implementation). Though you then still need Dovecot or co. for mailboxes (unless you prefer SSH for that).
Disclaimer: just reading about opensmtp, I'm using postfix
Dovecot is an IMAP server while exim, sendmail, postfix, and opensmtp (I guess) are SMTP servers (aka MTAs). An SMTP server is for sending/forwarding mails to or through, and IMAP (or POP3 or new-fangled jmap, supposedly) is what your mail program uses to browse your received mails and mailboxes etc.
> There have been many Exim bugs like this, why are people still running it?
Flexibility, mostly. It's configuration file includes a programming language of sorts, which means most things can be done write resorting to plugins or worse - having to write one.
Just in case any Exim users are reading here, you might want to be aware that Exim also does not check TLS certificates reliably, so any authentication credentials (as well as message contents, of course) that you might be transmitting via TLS to a remote server, using Exim as the client, can be intercepted by a MitM if the remote host is specified as a DNS name:
When I read about email being too hard, I hear about configuration headaches, deliverability, and spam, but the real reason that I outsource email is because of security. The horrible history of MTA security drives me into a very conservative mail strategy. Short of DJB devoting his life to qmail, I don't know if this problem can be solved.
"The mail server survey published on September 1 by E-Soft Inc, a company specializing in web server surveys, says that Exim is currently the most used MX server with 57.13% out of a total of 1,740,809 mail servers, representing 507,200 Exim servers being visible on the internet and accepting connections."
Exim is a mail transfer agent (MTA) used on Unix-like operating systems. [...] In August 2019 [...] approximately 57% of the publicly reachable mail-servers on the Internet ran Exim.
Yikes.
edit: This might be a better summary of the vulnerability: https://www.tenable.com/blog/cve-2019-15846-unauthenticated-...