There is a rather odd bug in several versions of the popular Exim mail transfer agent (MTA) software that can allow an attacker to execute arbitrary commands on remote mail servers under some specific conditions. The maintainers of Exim have released a patch for the flaw, but there are some exploit details circulating.
The vulnerability affects versions 4.87 through 4.91 of Exim in their default configurations, as well as in some other configurations. Researchers at Qualys recently discovered the flaw while doing a code review and found that they could exploit it remotely on default configurations with a sort of odd technique.
“This vulnerability is exploitable instantly by a local attacker (and by a remote attacker in certain non-default configurations). To remotely exploit this vulnerability in the default configuration, an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes). However, because of the extreme complexity of Exim's code, we cannot guarantee that this exploitation method is unique; faster methods may exist,” the Qualys advisory says.
Exim is designed to relay mail messages from one server to another and is used in a number of Linux distributions. The vulnerability (CVE-2019-10149) was introduced in version 4.87 and actually was fixed in Exim 4.92, before the maintainers knew it was a security issue. In the advisory, the Qualys researchers provide an example of a local exploit for the latest Debian release, but don’t provide the remote exploit code for default configurations. However, in some non-default configurations, remote exploitation is still possible.
“If the 'verify = recipient' ACL was removed manually by an administrator (maybe to prevent username enumeration via RCPT TO), then our local-exploitation method also works remotely,” the advisory says.
Exim’s maintainers have released a patch for the vulnerable versions and it has been pushed to the private Git repository available to the distributions that use Exim. The vulnerability was meant to remain private until June 11, but details of the bug began to leak, so the advisory went public June 5, along with the limited information about the exploits.
“We believe that it makes no sense to delay this any longer than that: this vulnerability is trivially exploitable in the local and non-default cases (attackers will have working exploits before that, public or not); and in the default case, a remote attack takes a long time to succeed (to the best of our knowledge),” the advisory says.