Exim – remote attacker can execute programs with root privileges | Hacker News Reader

Exim – remote attacker can execute programs with root privileges

lists.exim.org

142 pointseternalny169 comments

From https://en.wikipedia.org/wiki/Exim:

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

cPanel I believe still utilizes Exim which I suspect drives that number up.

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.

That is indeed correct.

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.

https://www.tenable.com/blog/cve-2019-15846-unauthenticated-...

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.

The most we know yet is this post:

https://www.openwall.com/lists/oss-security/2019/09/07/2

That implies it is the processing from the spool that is at fault; something is serialized and later read back.

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.

Here is an explicit discussion of how Exim handles this sort of issue:

* https://www.exim.org/exim-html-3.20/doc/html/spec_55.html

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.

You shouldn't use root to bind to port 25; just the capability CAP_NET_BIND_SERVICE

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.

[1] https://stackoverflow.com/questions/413807/is-there-a-way-fo...

[2] https://lwn.net/Articles/266521/

[3] https://en.wikipedia.org/wiki/Exim#Origin

[4] https://security.stackexchange.com/questions/71922/postfix-m...

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.

Or use Postfix, it is separated this way.

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 I still love qmail.

Why not use capabilities instead? Then root privileges are not required.

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.

C at its finest https://github.com/Exim/exim/commit/cdc7f9a9667ecf31d803fc8d...

That commit is just a fixup of the prior which the author probably intended to rebase and squash together.

The actual commit for this vuln is here: https://github.com/Exim/exim/commit/2600301ba6dbac5c9d640c87...

    *(++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.

I have to say that I've gotten code sent to me over Facebook Messenger that looks better-formatted than that thing.

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.

There have been many Exim bugs like this, why are people still running it? It's like the modern day sendmail.

https://www.cvedetails.com/vendor/10919/Exim.html 12 RCE CVE entries since the CVE system started.

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.

Debian ships with it. That's why I "use" it.

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

I chose it because it is really easy to set up and configure. That alone made it a much better choice than Sendmail, and I stuck with it.

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

Interestingly, other panels seem to use other SMTP servers: https://www.liquidweb.com/kb/comparison-of-the-four-major-se...

Interesting that this turns out to be a supply-chain/buried dependency problem just like so many other things in infosec.

What should people be using instead?

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.

I run Postfix. The author (Wietse) himself is very active on the mailinglist and happy to answer questions.

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.

I'm well aware of this distinction, yet it's also part of the equation when looking at "how to secure my email-server"

Notqmail ;)

An E-Mail client not written in C to start with.

> An E-Mail client not written in C to start with.

Exim is an SMTP server (MTA), not an email client (MUA).

Fair enough. Doesn't fix the buffer overflow though.

Which non-C MTA would you recommend?

There's maddy, but it's very new and not very popular.

No experience but there seems to be one here: https://james.apache.org/

It has "enterprise" in the name though so it's unlikely to be very robust or secure.

Someone using a rust implementation of telnet listening to port 25 to answer incoming requests.

Thunderbird, given that the mix of JavaScript + C++ should be less of a problem for buffer overflows.

Otherwise, business opportunity for other language communities.

> Thunderbird

Thunderbird is an MUA and is not a substitute for an MTA like Exim.

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

https://lists.exim.org/lurker/message/20181228.202226.22d1c4...

I just tested version 4.92, which is still affected, and it doesn't seem like there is any interest in fixing this vulnerability.

The release announcement itself directly states not to use TLS as a mitigation.

Yet another buffer overflow CVE....

Some mitigations mentioned in https://lists.exim.org/lurker/message/20190906.185037.1ff8bb...:

> Add - as part of the mail ACL (the ACL referenced by the main config option "acl_smtp_mail"):

     deny    condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni}}}}
     deny    condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_peerdn}}}}

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.

> Details: doc/doc-txt/cve-2019-15846 in the downloaded source tree

I can’t find this file in the Git repository. Does anyone know where it is?

It's not on master: https://github.com/Exim/exim/tree/exim-4.92.2%2Bfixes/doc/do...

Thanks.

It's in doc/cve-2019-15846 in the latest release tarballs. https://ftp.exim.org/pub/exim/exim4/

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

The fix: https://github.com/Exim/exim/commit/2600301ba6dbac5c9d640c87...

> Do not offer TLS for incomming connections (tls_advertise_hosts). This mitigation is not* recommended!*

No kidding? Turning off TLS isn't an option at many installations. It's gotta work.

This kind of thing (among others) is why I've lost all faith in cryptocurrencies.

Well that's like saying the USPS is unreliable, so therefore banks are not to be trusted

Heartbleed was the start of my fatalistic view of computer security.

I just don't trust data to be secure AND persistent.

Would any of the people downvoting me stake their life on keeping a short string of characters secure on a connected computer forever?

I wouldn't stake my life on any bank, either.

Exim is a mail transfer agent.

Reply on news.ycombinator.com