Exim Vulnerability (CVE-2019-16928): Global Exposure Details and Remediation Advice

Last updated at Wed, 24 Jan 2024 21:42:53 GMT

This blog post was co-authored by Kwan Lin and Greg Wiseman.

What is Exim?

Exim is a widely used mail transfer agent (MTA) that was initially implemented for Unix-like systems, but has since been ported to other platforms like Microsoft Windows. It often functions as the backbone to email delivery systems and is responsible for keeping as much as 60% of email servers happily processing ~spam~ email.

Background on the Exim vulnerabilities

On Sept. 27, 2019, CVE-2019-16928 was promulgated, indicating that all versions from 4.92.0 through 4.92.2 were vulnerable to a heap-based buffer overflow that could potentially allow for denial of service or arbitrary code execution on Exim mail servers. Exim version 4.92.3 was promptly released to remedy the identified vulnerability, and all versions prior to the latest release were deemed obsolete by the Exim project maintainers (although some operating system distributions support backporting fixes independently).

As we have observed in the past, despite urgent communications by software vendors and package maintainers, system administrators for any number of reasons tend to dawdle when implementing recommended remedies, even in the presence of viable threats.

Exim vulnerability exposure across the world

When we used Sonar to scan the internet and then applied Recog to fingerprint for Exim, we found approximately 4.75 million Exim assets, of which 72.5% were some variant of Exim 4.92.*.

As a preliminary analysis, we took a stab at getting a sense of how many Exim 4.92.* systems were identifiable on the internet on a state-level basis to gain a sense of the possible national attack surface. Unsurprisingly, the United States and a number of other developed states lead the pack in terms of Exim exposure.

Before we get much further, please note that the scanner-based data we’re leveraging here was collected on Sept. 19 and therefore predates the Sept. 27 announcement and patch. This means it is possible that there are fewer exposed pre-4.92.3 systems today—though probably not by much. We’ll follow up on a future date with another Sonar scan to determine the change in composition of Exim 4.92.* versions.

While a state-level examination is interesting, Exim is more likely deployed on a provider-level basis, so an autonomous system view would likely be more appropriate to gain a sense of exposure.

We identified the distribution of autonomous systems with the most significant manifestations of Exim 4.92.*:

We further delved into the breakdown of 4.92.* sub-versions present across the most prevalent sets of autonomous systems. In general, we found that version 4.92.0 remains most prevalent, despite the prior release of CVE-2019-158466 on Sept. 6 that revealed a severe remote code execution vulnerability in Exim version 4.92.2 that was intended to remedy that particular vulnerability. In this case, note that the data we have to work with comes after the release of updates intended to remedy a severe vulnerability, indicating that even without the identification of the latest CVE, there were already numerous Exim implementations that were vulnerable to a known threat for which a remedy was readily available.

How vulnerable is Exim 4.92.*, exactly?

Through a combination of recog fingerprinting and Sonar scanning, we were able to find presence of Exim 4.92.* on the usual SMTP ports across various devices exposed on the internet:

When we take that information and turn it around to look at the inbound activity we see on our Lorelei sensors—specifically, the number of non-researcher distinct sources (i.e., likely malicious) attempting to connect to ports on our honeypots that are often utilized by the Exim implementations we discovered—we observe a steady stream of inbound sources.

Given that Project Lorelei does not broadcast its presence, we can surmise that these attempted connections to our honeypots on ports 25, 465, and 587 are the results of indiscriminate scanning by malicious actors.

If we combine the two findings that there are many inadequately patched Exim mail servers present on the internet and that there are numerous likely malicious sources attempting connections to ports commonly utilized by Exim servers, we can conclude that it is very probable that Exim servers will be compromised by the vulnerabilities identified in CVE-2019-16928.

Distribution-specific notes

It can also be worthwhile to look at security advisories for specific Linux distributions to determine which are (or are not) affected by a vulnerability. Administrators may know which vendor their systems are from without having detailed knowledge of which MTA software is bundled by default.

Red Hat, for example, claims to be unaffected because they have not shipped Exim since RHEL 5, and the version there does not contain the vulnerable code introduced in 4.92. This should also be the case for CentOS, which tracks Red Hat as its upstream. The same goes for Amazon Linux.

Debian, on the other hand, has published a fix for buster (version 10) but notes that previous releases like Jessie and Stretch are not affected. Likewise, Ubuntu (a downstream distribution from Debian) has a fix for their 19.04 release (Disco Dingo) and notes on their CVE page that earlier versions are unaffected.

SUSE also reports that their software is not vulnerable to CVE-2019-16928. However, they also stated this for the previous major Exim flaw (CVE-2019-15846), while linking to an advisory for openSUSE Leap. However, it seems unlikely that Leap is affected given its Exim is based on version 4.88.

It’s worth noting here that most Linux vendors fix vulnerabilities such as CVE-2019-16928 via backporting. This means that only the minimum changes required to fix a vulnerability are introduced to an older version of the vulnerable package. This typically does not update the version string reported by banners, which is one caveat to the data collected via our SMTP studies. On the other hand, many of the most popular distributions actually ship versions prior to 4.92, meaning there’s a decent chance that banners showing 4.92.* (before 4.92.3) do, in fact, reflect vulnerable services.