Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Jun 2019 17:28:21 +0000
From: Qualys Security Advisory <>
To: "" <>
Subject: Re: CVE-2019-10149: Exim 4.87 to 4.91: possible remote

Hi all,

On Wed, Jun 05, 2019 at 05:19:44PM +0200, Heiko Schlittermann wrote:
> The fix for CVE-2019-10149 is public now.
> Sorry for confusion about the public release. We were forced to react,
> as details leaked.

As per the distros list policy:

Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.

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


Qualys Security Advisory

The Return of the WIZard: RCE in Exim (CVE-2019-10149)


Local exploitation
Remote exploitation
- Non-default configurations
- Default configuration

    Boromir: "What is this new devilry?"
    Gandalf: "A Balrog. A demon of the Ancient World."
        -- The Lord of the Rings: The Fellowship of the Ring


During a code review of the latest changes in the Exim mail server
(, we discovered an RCE vulnerability
in versions 4.87 to 4.91 (inclusive). In this particular case, RCE means
Remote *Command* Execution, not Remote Code Execution: an attacker can
execute arbitrary commands with execv(), as root; no memory corruption
or ROP (Return-Oriented Programming) is involved.

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.

Exim is vulnerable by default since version 4.87 (released on April 6,
2016), when #ifdef EXPERIMENTAL_EVENT became #ifndef DISABLE_EVENT; and
older versions may also be vulnerable if EXPERIMENTAL_EVENT was enabled
manually. Surprisingly, this vulnerability was fixed in version 4.92
(released on February 10, 2019):

but was not identified as a security vulnerability, and most operating
systems are therefore affected. For example, we exploit an up-to-date
Debian distribution (9.9) in this advisory.

Local exploitation

The vulnerable code is located in deliver_message():

6122 #ifndef DISABLE_EVENT
6123       if (process_recipients != RECIP_ACCEPT)
6124         {
6125         uschar * save_local =  deliver_localpart;
6126         const uschar * save_domain = deliver_domain;
6128         deliver_localpart = expand_string(
6129                       string_sprintf("${local_part:%s}", new->address));
6130         deliver_domain =    expand_string(
6131                       string_sprintf("${domain:%s}", new->address));
6133         (void) event_raise(event_action,
6134                       US"msg:fail:internal", new->message);
6136         deliver_localpart = save_local;
6137         deliver_domain =    save_domain;
6138         }
6139 #endif

Because expand_string() recognizes the "${run{<command> <args>}}"
expansion item, and because new->address is the recipient of the mail
that is being delivered, a local attacker can simply send a mail to
"${run{...}}@...alhost" (where "localhost" is one of Exim's
local_domains) and execute arbitrary commands, as root
(deliver_drop_privilege is false, by default):


Remote exploitation

Our local-exploitation method does not work remotely, because the
"verify = recipient" ACL (Access-Control List) in Exim's default
configuration requires the local part of the recipient's address (the
part that precedes the @ sign) to be the name of a local user:


Non-default configurations

We eventually devised an elaborate method for exploiting Exim remotely
in its default configuration, but we first identified various
non-default configurations that are easy to exploit remotely:

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

- If Exim was configured to recognize tags in the local part of the
  recipient's address (via "local_part_suffix = +* : -*" for example),
  then a remote attacker can simply reuse our local-exploitation method
  with an RCPT TO "balrog+${run{...}}@...alhost" (where "balrog" is the
  name of a local user).

- If Exim was configured to relay mail to a remote domain, as a
  secondary MX (Mail eXchange), then a remote attacker can simply reuse
  our local-exploitation method with an RCPT TO "${run{...}}@...zad.dum"
  (where "khazad.dum" is one of Exim's relay_to_domains). Indeed, the
  "verify = recipient" ACL can only check the domain part of a remote
  address (the part that follows the @ sign), not the local part.

Default configuration



We thank Exim's developers, Solar Designer, and the members of

"The Return of the WIZard" is a reference to Sendmail's ancient WIZ and
DEBUG vulnerabilities:


2019-05-27: Advisory sent to security@...m.

2019-05-28: Advisory sent to distros@...nwall.


This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Qualys email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails (“spam”). If you have any concerns about this process, please contact us.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.