Bug 1748397 (CVE-2019-15846) - CVE-2019-15846 exim: out-of-bounds access in string_interpret_escape() leading to buffer overflow in the SMTP delivery process
Summary: CVE-2019-15846 exim: out-of-bounds access in string_interpret_escape() leadin...
Alias: CVE-2019-15846
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1749761 1749838
Blocks: 1748403
TreeView+ depends on / blocked
Reported: 2019-09-03 14:02 UTC by msiddiqu
Modified: 2019-09-10 01:58 UTC (History)
9 users (show)

Fixed In Version: exim 4.92.2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-09-06 21:42:27 UTC

Attachments (Terms of Use)

Description msiddiqu 2019-09-03 14:02:13 UTC
Quoting form the pre-release of the Exim project security advisory:

The SMTP Delivery process in all versions up to and including Exim 4.92.1 has a Buffer Overflow.  In the default runtime configuration, this is exploitable with crafted Server Name Indication (SNI) data during a TLS negotiation. In other configurations, it is exploitable with a crafted client TLS certificate.

Comment 1 msiddiqu 2019-09-03 14:03:58 UTC

Name: the Exim project
Upstream: Zerons, Qualys

Comment 5 Tomas Hoger 2019-09-05 09:15:09 UTC
This issue is getting fixed in the upstream version 4.92.2.

Comment 6 Tomas Hoger 2019-09-05 20:37:19 UTC
The issue here is in the Exim's internal function string_interpret_escape():


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

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


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.

Comment 7 Tomas Hoger 2019-09-05 21:08:12 UTC

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.

Comment 8 Tomas Hoger 2019-09-06 12:32:30 UTC
Upstream commit:


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.


Comment 9 Tomas Hoger 2019-09-06 12:34:26 UTC
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:


Comment 10 Tomas Hoger 2019-09-06 14:34:48 UTC
Public now via upstream commits (linked above) and the upstream advisory:


Comment 11 Tomas Hoger 2019-09-06 14:37:24 UTC
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:


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.

Comment 12 Tomas Hoger 2019-09-06 14:38:54 UTC
Created exim tracking bugs for this issue:

Affects: epel-all [bug 1749838]

Comment 13 Tomas Hoger 2019-09-06 14:43:56 UTC
External References:


Comment 14 Product Security DevOps Team 2019-09-06 21:42:27 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Note You need to log in before you can comment on or make changes to this bug.