CVE-2017-16943: Exim BDAT Use-After-Free

Last updated at Thu, 30 Nov 2017 12:48:14 GMT

Exim BDAT Use-After-Free (CVE-2017-16943): What You Need To Know

Turns out, the Exim Internet Mailer team was busy over the Thanksgiving holiday, after security researcher “meh” reported a pair of vulnerabilities in the wildly popular open source email server. The first, a critical remote execution vulnerability, is a use-after-free (UAF) vulnerability, dubbed CVE-2017-16943 and the second is a recursive denial of service (DoS), CVE-2017-16944. If you’re running exim in your environment -- and according to reports, hundreds of thousands of you are -- then you need to mitigate around this right now.

Luckily, mitigation is a snap: just disable the (somewhat experimental) chunking option in your exim configuration, as recommended by exim developer Phil Pennock. In the meantime, exim 4.90 is still in the works -- look for that release, or a backported patch, to hit your distribution shortly.

TLDR: Exim has some pretty severe vulnerabilities involving the BDAT chunked data transfer mechanism, so turn that off until updates are available.

Right, but what’s exim BDAT UAF mean?

That’s a fine question! Let’s break it down:

exim: Exim is, for many organizations, the backbone of email services. It’s the default mail transfer agent (MTA), or email server, for Debian and Ubuntu Linux, and is present on many other linux builds. Other MTAs include Sendmail, Postfix, and Exchange. If you’re running any of those, you’re in the clear.

BDAT: BDAT is an optional mechanism for sending Binary DATa over email in “chunks,” and is defined in RFC 3030. If chunking is disabled, your mail server will only accept binary data as sent by the original DATA command. Although it’s less efficient (and thus, a little slower), it shouldn’t be a problem for your site. Note that this chunking functionality is enabled by default in recent versions of exim.

UAF: A use-after-free bug is defined in the Common Weakness Enumeration as CWE-416, and is one of a class of classical memory allocation bugs. Sometimes, UAF bugs lead to access violations, which can crash the running service. More rarely, a UAF can be leveraged to execute the code of the attacker’s choice. That’s the case here for CVE-2017-16943.

What’s the risk posed by these exim vulnerabilities?

For the DoS issue (CVE-2017-16944), the worst that can happen when it’s exploited is that you’re out of the email business until a restart. We figure a “high” CVSS 7.5 score for this scenario. That’s pretty bad, of course -- people often treat email as time sensitive communications, so that alone should be enough to convince you that the mitigation of setting chunking_advertise_hosts in your exim configuration file to a nil value is worth your time.

For the UAF issue (CVE-2017-16943), this looks like a “critical” CVSS 9.8 vulnerability. The worst that can happen is that an attacker can seize control of your email server -- therefore, they can read, write, and delete email from, and as, any user, use the email server itself to launch further attacks on both internal and internet-facing assets, and likely use this vulnerability to create a self-propagating worm that can pop other exim servers that try to talk to the compromised machine. It’s about as bad a bug can be.

That said, we don’t have the internet-wide monoculture of email servers today like we had during the storied Morris worm of 1988. There are lots of email servers that aren’t exim, and many of those exim servers already have chunking disabled, so this issue isn’t an unmitigated disaster for the internet. It’s just bad for you if your email server is vulnerable.

Is my mail server vulnerable?

If you’re one of the many organizations that runs one of the latest versions of exim (4.88 and 4.89), then you need to act pretty much now. As it happens, exim 4.88 also had some other problems with chunking, and it was recommended to disable it in the exact same way it’s disabled to avoid these bugs. So, if you followed that advice in the spring, then you’re in the clear. If you didn’t, do it now. Chunking is unsafe at any speed, as far as exim is concerned.

For everyone else, you don’t have a problem. If you’re on Exchange, Postfix, Sendmail, or one of the mysterious mail servers running in the cloud (like Gmail or Outlook365), then you’re fine.

How can Rapid7 help?

We’re working on Metasploit modules and authenticated InsightVM checks right this moment, and will update this blog post just as soon as we have those mechanisms in place for customers to test their own networks. For Metasploit, in particular, we expect modules pretty quickly -- this is the kind of bug that Metasploit excels at leveraging for penetration testing purposes. Check back on this blog for updates when we ship those out.

Update: Sonar study for exim exposure

We kicked off a quick Sonar study to measure the internet exposure of the exim vulnerability, and broke out the results by geolocation and service provider. You can see those results here, but the big takeaway is that we're just not seeing the "4 million exposed servers" number that's being bandied about the twittersphere. It's still a lot (just about 200,000 exim servers of the affected version that are advertising chunking capabilities), but it's not in the millions.

Update: Remote Nexpose Checks

On Tuesday evening, we shipped remote, unauthenticated checks for the two exim issues CVE-2017-16943, CVE-2017-16944. Nexpose and InsightVM customers should see these checks available for immediate use.