Bug 1748397 (CVE-2019-15846)

Acknowledgments:

Name: the Exim project
Upstream: Zerons, Qualys

This issue is getting fixed in the upstream version 4.92.2.

The issue here is in the Exim's internal function string_interpret_escape():

https://git.exim.org/exim.git/blob/cf84d126bc:/src/src/string.c#l217

This function processes a single backslash escaped sequence and returns the character that is represented by the escape sequence.  The function fails to correctly handle situation when backslash is the last character of the input string, and incorrectly sets the pointer that is supposed to point to the last character of the escape sequence upon function exit.  A function caller than subsequently advances the pointer past the buffer boundary.  That leads to out-of-bounds read when the caller attempts to process the input string following the escape sequence.  Additionally, this may lead to out-of-bounds write when unescaped string is written (to the same or different buffer).

The analysis of this issue was performed by the Qualys Security Advisory team.  Quoting their findings:

"""
- From an attacker's point of view, most calls to
  string_interpret_escape() are uninteresting. For example, nextitem()
  in src/filter.c checks for buffer overflows, and string_dequote()
  seems to process trusted strings only (strings from configuration
  files).

- On the other hand, string_unprinting() is very interesting:

  - It is used in tls_import_cert() (for peercert, for example); but
    certificates are in PEM format (i.e., base64) and hence unlikely to
    contain the problematic backslash-null-byte sequence.

  - It is used for peerdn and sni in src/spool_in.c; but peerdn is used
    only if client certificates are processed by Exim, and this is not
    the default (and although some sites use client-certificate
    authentication, this is not very common, and hence not very
    interesting for an attacker).

  - In any case, as long as Exim supports and accepts tls connections,
    an attacker can send an sni, and hence reach the problematic
    string_unprinting() and string_interpret_escape() functions.
"""

They further confirmed that the buffer overflow (out-of-bounds write) that is triggered via sni or peerdn processing is exploitable and can lead to code execution within a process that runs with root privileges, and it can be triggered by an unauthenticated remote attacker.

The only currently supported Red Hat product which includes Exim is Red Hat Enterprise Linux 5, with older Exim 4.63.  This version includes the buggy string_interpret_escape() function.  However, unlike recent Exim versions, it does not include string_unprinting() function and hence does not do peerdn and sni processing as described above.  The string_unprinting() function and its use for unquoting of peerdn and sni info from spool files was introduced in Exim 4.80 via the following commits:

https://git.exim.org/exim.git/commitdiff/c7396ac5dedeca5d791113782ae72b4bb67692e3
https://git.exim.org/exim.git/commitdiff/7be682ca5ebd9571a01b762195b11c34cd231830

As noted in the Qualys Security Advisory team's analysis, other uses of the string_interpret_escape() only process trusted inputs (typically inputs from various configuration files) and/or avoid buffer overflow via additional bounds checking or extension of output buffer as more data is being written.

Therefore, even though the version of Exim as shipped with Red Hat Enterprise Linux 5 includes the buggy string_interpret_escape() function, it does not expose the problem and is not affected by the remote code execution flaw.

Statement:

The flaw in the string_interpret_escape() function exists in the versions of Exim as shipped with Red Hat Enterprise Linux 5. However, it is not exposed to untrusted inputs and therefore it can not be exploited to achieve remote code execution. Refer to Red Hat Bugzilla bug 1748397 for further technical details: https://bugzilla.redhat.com/show_bug.cgi?id=1748397#c6

Exim mail server is not shipped with Red Hat Enterprise Linux 6, 7, and 8.

Upstream commit:

https://git.exim.org/exim.git/commitdiff/2600301ba6dbac5c9d640c87007a07ee6dcea1f4

The same change for the exim_dbmbuild tool, which includes a copy of the string_interpret_escape() function.  Note that this tool is not expected to be used on untrusted inputs, and hence the problem in it is not considered to have security impact.

https://git.exim.org/exim.git/commitdiff/66935633816a88460f5222f40dc29d1a4e877978
https://git.exim.org/exim.git/commitdiff/cdc7f9a9667ecf31d803fc8d1a31b466284360bd

In reply to comment #6:
> The analysis of this issue was performed by the Qualys Security Advisory
> team.  Quoting their findings:

Full write-up from the Qualys Security Advisory team can be found in:

https://git.exim.org/exim.git/blob/2600301ba6:/doc/doc-txt/cve-2019-15846/qualys.mbx

Public now via upstream commits (linked above) and the upstream advisory:

http://exim.org/static/doc/security/CVE-2019-15846.txt

Upstream advisory provides the following mitigation instructions that can be used to block exploitation using sni or peerdn as described in comment 6 above.

Quoting the Mitigation section of the upstream advisory:

"""
Mitigation
==========

Do not offer TLS. (This mitigation is not recommended.)

For a attacking SNI the following ACL snippet should work:

    # 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}}}}
"""

Note that this mitigation is not needed for the version of Exim as shipped with Red Hat Enterprise Linux 5.

Created exim tracking bugs for this issue:

Affects: epel-all [bug 1749838]

External References:

https://exim.org/static/doc/security/CVE-2019-15846.txt

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2019-15846