Exim 4.9.1 Remote Command Execution

2019.06.07
Credit: Qualys
Risk: High
Local: No
Remote: Yes
CWE: CWE-78

------------------------------------------------------------------------ Qualys Security Advisory The Return of the WIZard: RCE in Exim (CVE-2019-10149) ======================================================================== Contents ======================================================================== Summary Local exploitation Remote exploitation - Non-default configurations - Default configuration Acknowledgments Timeline 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 ======================================================================== Summary ======================================================================== During a code review of the latest changes in the Exim mail server (https://en.wikipedia.org/wiki/Exim), 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): https://github.com/Exim/exim/commit/7ea1237c783e380d7bdb86c90b13d8203c7ecf26 https://bugs.exim.org/show_bug.cgi?id=2310 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; 6127 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)); 6132 6133 (void) event_raise(event_action, 6134 US"msg:fail:internal", new->message); 6135 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 ------------------------------------------------------------------------ [...] ======================================================================== Acknowledgments ======================================================================== We thank Exim's developers, Solar Designer, and the members of distros@...nwall. "The Return of the WIZard" is a reference to Sendmail's ancient WIZ and DEBUG vulnerabilities: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0145 https://seclists.org/bugtraq/1995/Feb/56 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0095 http://www.cheswick.com/ches/papers/berferd.pdf ======================================================================== Timeline ======================================================================== 2019-05-27: Advisory sent to security@...m. 2019-05-28: Advisory sent to distros@...nwall.


Vote for this issue:
100%
0%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2019, cxsecurity.com

 

Back to Top