Patched Exim — patch again. Fresh Remote Command Execution in Exim 4.92 in one request

Recently, at the beginning of summer, there were widespread calls to update Exim to version 4.92 due to the CVE-2019-10149 vulnerability (Urgently update exim to 4.92 — active infections ongoing / Habr). It has recently been discovered that the malware Sustes decided to exploit this vulnerability.

Now all those who updated urgently can once again "rejoice": on July 21, 2019, researcher Zerons discovered a critical vulnerability in the Exim Mail Transfer Agent (MTA) when using TLS for versions from 4.80 to 4.92.1 inclusive, allowing remote code execution with privileged rights (CVE-2019-15846).

The vulnerability

The vulnerability exists when using both GnuTLS and OpenSSL libraries when establishing a secure TLS connection.

According to developer Heiko Schlittermann, the Exim configuration file by default does not use TLS, but many distributions create the necessary certificates during installation and include a secure connection. Also, newer versions of Exim set the option tls_advertise_hosts=* and generate the necessary certificates.

depends on the configuration. Most distros enable it by default, but Exim needs a certificate+key to work as a TLS server. Probably, Distros create a Cert during setup. Newer Exims have the tls_advertise_hosts option defaulting to «*» and create a self-signed certificate if none is provided.

The vulnerability itself lies in the incorrect handling of SNI (Server Name Indication, a technology introduced in 2003 in RFC 3546 to request the correct certificate for the domain name from the client, TLS SNI standard dissemination / WEBO Group Blog / Habr) during the TLS handshake. An attacker only needs to send an SNI that ends with a backslash («") and a null character (" ").

Researchers from Qualys discovered a bug in the string_printing(tls_in.sni) function, which involves incorrect escaping of «». As a result, a backslash is written in unescaped form to the print spool header file. This file is then read with privileged rights by the spool_read_header() function, leading to a heap overflow.

It's worth noting that currently Exim developers have created a PoC for the vulnerability with command execution on a remote vulnerable server, but it is not publicly available yet. Due to the ease of exploiting the bug, it’s only a matter of time, and quite a short one at that.

A more detailed investigation of the company Qualys can be found. here.

Use of SNI in TLS

Number of potentially vulnerable public servers

According to statistics from a major hosting provider E-Soft Inc as of September 1, version 4.92 is used on more than 70% of rented servers.

Version
Number of Servers
Percent

4.92.1
6471
1.28%

4.92
376436
74.22%

4.91
58179
11.47%

4.9
5732
1.13%

4.89
10700
2.11%

4.87
14177
2.80%

4.84
9937
1.96%

Other versions
25568
5.04%

Statistics from E-Soft Inc

If you turn to the search engine Shodan, out of 5,250,000 in the server database:

• about 3,500,000 use Exim 4.92 (about 1,380,000 using SSL/TLS);
• more than 74,000 use 4.92.1 (about 25,000 using SSL/TLS).

Thus, there are approximately 1.5 million.

Searching for Exim servers in Shodan

Protection

• The simplest, but not recommended option is not to use TLS, which will lead to the transmission of emails in plain text.
• A more preferable way to avoid exploitation of the vulnerability would be to upgrade to version Exim Internet Mailer 4.92.2.
• If upgrading or installing a patched version is not possible, you can set ACL in the Exim configuration for the option acl_smtp_mail with the following rules:

  # to be prepended to your mail acl (the ACL referenced
  # by the acl_smtp_mail main config option)
  deny    condition = ${if eq{}{${substr{-1}{1}{$tls_in_sni}}}}
  deny    condition = ${if eq{}{${substr{-1}{1}{$tls_in_peerdn}}}}

Source: habr.com