diff options
Diffstat (limited to 'doc/cve-2019-15846')
| -rw-r--r-- | doc/cve-2019-15846/cve.txt | 45 | ||||
| -rw-r--r-- | doc/cve-2019-15846/mitre.mbx | 84 | ||||
| -rw-r--r-- | doc/cve-2019-15846/posting-0.txt | 59 | ||||
| -rw-r--r-- | doc/cve-2019-15846/posting-1.txt | 59 | ||||
| -rw-r--r-- | doc/cve-2019-15846/posting-2.txt | 44 | ||||
| -rw-r--r-- | doc/cve-2019-15846/qualys.mbx | 175 |
6 files changed, 466 insertions, 0 deletions
diff --git a/doc/cve-2019-15846/cve.txt b/doc/cve-2019-15846/cve.txt new file mode 100644 index 0000000..b52722b --- /dev/null +++ b/doc/cve-2019-15846/cve.txt @@ -0,0 +1,45 @@ +CVE ID: CVE-2019-15846 +Date: 2019-09-02 (CVE assigned) +Credits: Zerons <sironhide0null@gmail.com> for the initial report + Qualys https://www.qualys.com/ for the analysis +Version(s): all versions up to and including 4.92.1 +Issue: A local or remote attacker can execute programs with root + privileges. + +Conditions to be vulnerable +=========================== + +If your Exim server accepts TLS connections, it is vulnerable. This does +not depend on the TLS libray, so both, GnuTLS and OpenSSL are affected. + +Details +======= + +The vulnerability is exploitable by sending a SNI ending in a +backslash-null sequence during the initial TLS handshake. The exploit +exists as a POC. For more details see the document qualys.mbx + +Mitigation +========== + +Do not offer TLS. (This mitigation is not recommended.) + +Fix +=== + +Download and build a fixed version: + + Tarballs: https://ftp.exim.org/pub/exim/exim4/ + Git: https://github.com/Exim/exim.git + - tag exim-4.92.2 + - branch exim-4.92.2+fixes + +The tagged commit is the officially released version. The +fixes branch +isn't officially maintained, but contains the security fix *and* useful +fixes. + +If you can't install the above versions, ask your package maintainer for +a version containing the backported fix. On request and depending on our +resources we will support you in backporting the fix. (Please note, +the Exim project officially doesn't support versions prior the current +stable version.) diff --git a/doc/cve-2019-15846/mitre.mbx b/doc/cve-2019-15846/mitre.mbx new file mode 100644 index 0000000..ddd6f9c --- /dev/null +++ b/doc/cve-2019-15846/mitre.mbx @@ -0,0 +1,84 @@ +From cve-request@mitre.org Mon Sep 2 18:12:21 2019 +Return-Path: <cve-request@mitre.org> +Authentication-Results: mx.net.schlittermann.de; iprev=pass + (smtpvbsrv1.mitre.org) smtp.remote-ip=198.49.146.234; spf=pass + smtp.mailfrom=mitre.org; dkim=pass header.d=mitre.org header.s=selector1 + header.a=rsa-sha256; dmarc=pass header.from=mitre.org +From: cve-request@mitre.org +To: hs@schlittermann.de +Cc: cve-request@mitre.org +Subject: Re: [scr749683] one CVE +Date: Mon, 2 Sep 2019 12:12:12 -0400 (EDT) +MIME-Version: 1.0 +Content-Transfer-Encoding: 8bit +Content-Type: text/plain; charset=utf-8 +Status: RO + +> [Suggested description] +> The SMTP Delivery process in 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. +> +> ------------------------------------------ +> +> [Additional Information] +> It's the first CVE I request, so if there is anything missing, please tell me +> +> ------------------------------------------ +> +> [Vulnerability Type] +> Buffer Overflow +> +> ------------------------------------------ +> +> [Vendor of Product] +> Exim Development Team +> +> ------------------------------------------ +> +> [Affected Product Code Base] +> Exim - 4.92.1 +> +> ------------------------------------------ +> +> [Affected Component] +> SMTP Delivery process +> +> ------------------------------------------ +> +> [Attack Type] +> Remote +> +> ------------------------------------------ +> +> [Impact Code execution] +> true +> +> ------------------------------------------ +> +> [Attack Vectors] +> To exploit the vulnerability the attacker needs a crafted client TLS +> certificate or a crafted SNI. While the first attack vector needs a +> non-default runtime configuration, the latter one should work with the +> default runtime config. +> +> ------------------------------------------ +> +> [Discoverer] +> zerons zerons <sironhide0null@gmail.com> +> +> ------------------------------------------ +> +> [Reference] +> http://exim.org/static/doc/security/CVE-2019-15846.txt + +Use CVE-2019-15846. + + +-- +CVE Assignment Team +M/S M300, 202 Burlington Road, Bedford, MA 01730 USA +[ A PGP key is available for encrypted communications at + http://cve.mitre.org/cve/request_id.html ] + diff --git a/doc/cve-2019-15846/posting-0.txt b/doc/cve-2019-15846/posting-0.txt new file mode 100644 index 0000000..90d754d --- /dev/null +++ b/doc/cve-2019-15846/posting-0.txt @@ -0,0 +1,59 @@ +To: distros@vs.openwall.org, exim-maintainers@exim.org +From: [ do not use a dmarc protected sender ] + +** EMBARGO *** This information is not public yet. + +CVE ID: CVE-2019-15846 +Credits: Zerons <sironhide0null@gmail.com>, Qualys +Version(s): all versions up to and including 4.92.1 +Issue: 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. +Details: doc/doc-txt/cve-2019-15846 in the downloaded source tree + +Contact: security@exim.org + +Proposed Timeline +================= + +2019-09-03: + - This notice to distros@vs.openwall.org and exim-maintainers@exim.org + - Open limited access to our security Git repo. See below. + +2019-09-04: + - Heads-up notice to oss-security@lists.openwall.com, + exim-users@exim.org, and exim-announce@exim.org + about the upcoming security release + +2019-09-06 10:00 UTC: + - Coordinated relase date + - Publish the patches in our official and public Git repositories + and the packages on our FTP/HTTP(S) server. + +Downloads +========= + +The downloads mentioned below are accessible only for a limited set of SSH +keys. At CRD they will be mirrored to the public repositories. +(Note: the repo names changed from the recently used ones.) + +For release tarballs (exim-4.92.2): + + git clone --depth 1 ssh://git@git.exim.org/exim-packages-security + +The package files are signed with my GPG key. + +For the full Git repo: + + git clone ssh://git@exim.org/exim-security + - tag exim-4.92.2 + - branch exim-4.92.2+fixes + +The tagged commit is the officially maintained version. The tag is signed +with my GPG key. The +fixes branch isn't officially maintained, but +contains useful patches *and* the security fix. The relevant commit +is signed with my GPG key. + +If you need help backporting the patch, please contact us directly. diff --git a/doc/cve-2019-15846/posting-1.txt b/doc/cve-2019-15846/posting-1.txt new file mode 100644 index 0000000..d22b85c --- /dev/null +++ b/doc/cve-2019-15846/posting-1.txt @@ -0,0 +1,59 @@ +To: oss-security@lists.openwall.com, exim-users@exim.org, + exim-announce@exim.org +From: [ do not use a dmarc protected sender ] + +*** Note: EMBARGO is still in effect *** +*** Distros must not publish any detail yet *** + +Head up! Security release ahead! + +CVE ID: CVE-2019-15846 +Version(s): up to and including 4.92.1 +Issue: A local or remote attacker can execute programs with root + privileges. +Details: Will be made public at CRD. + +Coordinated Release Date (CRD) for Exim 4.92.2: 2019-09-06 10:00 UTC + +Contact: security@exim.org + +Proposed Timeline +================= + +2019-09-03: + - initial notification to distros@openwall.org and + exim-maintainers@exim.org + +2019-09-04: <-- NOW + - This Heads-up notice to oss-security@lists.openwall.com, + exim-users@exim.org, and exim-announce@exim.org + +2019-09-06 10:00 UTC: + - Coordinated relase date + - Publish the patches in our official and public Git repositories + and the packages on our FTP server. + +Downloads available starting at CRD +==================================== + +The downloads are not yet available. They will be made available +at the above mentioned CRD. + +Release tarballs (exim-4.92.2): + + https://ftp.exim.org/pub/exim/exim4/ + +The package files are signed with my GPG key. + +The full Git repo: + + https://git.exim.org/exim.git + https://github.com/Exim/exim [mirror of the above] + - tag exim-4.92.2 + - branch exim-4.92.2+fixes + +The tagged commit is the officially released version. The tag is signed +with my GPG key. The +fixes branch isn't officially maintained, but +contains useful patches *and* the security fix. The relevant commit is +signed with my GPG key. The old exim-4.92.1+fixes branch is being functionally +replaced by the new exim-4.92.2+fixes branch. diff --git a/doc/cve-2019-15846/posting-2.txt b/doc/cve-2019-15846/posting-2.txt new file mode 100644 index 0000000..20037dd --- /dev/null +++ b/doc/cve-2019-15846/posting-2.txt @@ -0,0 +1,44 @@ +To: exim-users@exim.org, exim-announce@exim.org, exim-maintainers@exim.org +From: [ do not use a dmarc protected sender ] + +CVE ID: CVE-2019-15846 +Credits: Zerons <sironhide0null@gmail.com>, Qualys +Version(s): all versions up to and including 4.92.1 +Issue: 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. +Details: doc/doc-txt/cve-2019-15846 in the downloaded source tree + +Coordinated Release Date (CRD) for Exim 4.92.2: + 2019-09-06 10:00 UTC + +Contact: security@exim.org + +We released Exim 4.92.2. This is a security update based on 4.92.1. + +Downloads +========= + +Starting at CRD the downloads will be available from the following +sources: + +Release tarballs (exim-4.92.2): + + https://ftp.exim.org/pub/exim/exim4/ + +The package files are signed with my GPG key. + +The full Git repo: + + https://git.exim.org/exim.git + https://github.com/Exim/exim [mirror of the above] + - tag exim-4.92.2 + - branch exim-4.92.2+fixes + +The tagged commit is the officially released version. The tag is signed +with my GPG key. The +fixes branch isn't officially maintained, but +contains useful patches *and* the security fix. The relevant commit is +signed with my GPG key. The old exim-4.92.1+fixes branch is being functionally +replaced by the new exim-4.92.2+fixes branch. diff --git a/doc/cve-2019-15846/qualys.mbx b/doc/cve-2019-15846/qualys.mbx new file mode 100644 index 0000000..66c1e8e --- /dev/null +++ b/doc/cve-2019-15846/qualys.mbx @@ -0,0 +1,175 @@ +From qsa@qualys.com Wed Aug 14 01:29:25 CEST 2019 +Date: Tue, 13 Aug 2019 23:29:25 +0000 +From: Qualys Security Advisory <qsa@qualys.com> +To: Heiko Schlittermann <hs@schlittermann.de> +Subject: Re: Help evaluating a Bug in Exim MTA +Return-Path: <qsa@qualys.com> +Authentication-Results: mx.net.schlittermann.de; iprev=pass + (mx0b-001ca501.pphosted.com) smtp.remote-ip=148.163.158.195; spf=pass + smtp.mailfrom=qualys.com; dkim=pass header.d=qualys.com header.s=qualyscom + header.a=rsa-sha256; dkim=pass header.d=qualys.onmicrosoft.com + header.s=selector2-qualys-onmicrosoft-com header.a=rsa-sha256; dmarc=none + header.from=qualys.com +Authentication-Results: ppops.net; spf=pass smtp.mailfrom=qsa@qualys.com +Status: O +Content-Length: 3899 +Lines: 80 + +Hi Heiko, + +On Mon, Aug 12, 2019 at 11:56:12PM +0200, Heiko Schlittermann wrote: +> So I'd say, you do not need to rush, but I'd like to close it sooner or +> later in either manner. + +OK, below is our preliminary analysis. First: + +- 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. + +Next question: is it possible to send an sni that is written to the +spool header file and that ends with the problematic backslash-null-byte +sequence? The answer is yes, because of what we believe is another bug, +in string_printing(): the sni is written to the spool header file via +string_printing(tls_in.sni), which escapes characters with backslash, +but does *not* escape the escaping character itself (backslash), +although it definitely should. + +This bug is what makes it possible to reach and trigger the bug in +string_unprinting() and string_interpret_escape(), with an sni that ends +in an unescaped backslash (followed by the terminating null byte). + +Last question: is this exploitable? The answer is, almost certainly, yes +(and, because spool_read_header() runs as root, this means remote root). + +The sni is read from the spool via string_unprinting(string_copy()), and +both string_unprinting() and string_copy() use store_get(): as a result, +the destination buffer is allocated right after the source buffer, and +the characters that are read out-of-bounds after the end of the source +buffer are the first characters of the destination buffer, which are +fully under the attacker's control. This results in a heap overflow +whose length and contents are both under the attacker's control (we +verified this). This is almost certainly exploitable. + +Our advice is to start the security-release process as soon as possible. +We know it is very painful, but we are really confident that this bug is +exploitable; we will try to confirm this in the next few days. We also +believe that an Exim server must support and accept tls connections to +be remotely exploitable (via sni). + +During our analysis of this bug, we probably spotted three other bugs: + +- The unescaped backslash in string_printing() that we mentioned above. + +- A bug in spool_read_header(): before the for (;;) loop, p is set to + big_buffer + 2; and inside the loop, big_buffer may be re-allocated; + but p is never updated. This can lead to a use-after-free (we did not + assess the security impact of this bug, though). + +- A bug in spool_write_header(): the return value of tls_export_cert() + is not checked (for ourcert, but more importantly, for peercert). If + this function fails (maybe because big_buffer is not big enough), then + big_buffer may be uninitialized or unterminated, and garbage may be + written to the spool file (we did not assess the security impact of + this bug, either). + +We are at your disposal for questions, comments, and further +discussions. Thank you very much for reaching out! With best regards, + +-- +the Qualys Security Advisory team +From qsa@qualys.com Mon Aug 19 00:23:03 CEST 2019 +Date: Sun, 18 Aug 2019 22:23:03 +0000 +From: Qualys Security Advisory <qsa@qualys.com> +To: Heiko Schlittermann <hs@schlittermann.de> +Subject: Re: Help evaluating a Bug in Exim MTA +Return-Path: <qsa@qualys.com> +Authentication-Results: mx.net.schlittermann.de; iprev=pass + (mx0a-001ca501.pphosted.com) smtp.remote-ip=148.163.156.198; spf=pass + smtp.mailfrom=qualys.com; dkim=pass header.d=qualys.com header.s=qualyscom + header.a=rsa-sha256; dkim=pass header.d=qualys.onmicrosoft.com + header.s=selector2-qualys-onmicrosoft-com header.a=rsa-sha256; dmarc=none + header.from=qualys.com +Authentication-Results: ppops.net; spf=pass smtp.mailfrom=qsa@qualys.com +Status: RO +Content-Length: 2484 +Lines: 59 + +Hi Heiko, + +On Tue, Aug 13, 2019 at 11:29:25PM +0000, Qualys Security Advisory wrote: +> we are really confident that this bug is exploitable + +We can confirm that this bug is indeed exploitable: we wrote a +rudimentary exploit that remotely obtains root privileges (because +deliver_message() runs as root). + +Some general notes on this exploit: + +- To the best of our knowledge, the string_interpret_escape() bug + (backslash-null) is remotely exploitable if and only if Exim supports + and accepts TLS connections (because the only attack vector that we + know of is the string_unprinting() of SNI). + +- Both OpenSSL and GnuTLS installations are exploitable. + +- Our exploit is Linux-specific (because our heap-overflow exploitation + is specific to glibc's malloc implementation), but works on both i386 + and amd64. + +Some detailed notes on this exploit: + +- First, we connect to Exim with TLS and send an SNI that ends with + backslash-null (this SNI is written unmodified to the spool because of + the unescaped-backslash bug in string_printing2()). + +- Second, we exploit the backslash-null bug in string_interpret_escape() + (our SNI is read from the spool and unescaped by string_unprinting()), + and we transform this out-of-bounds read into an out-of-bounds write + (a heap overflow). + +- Next, we use this heap overflow to overwrite the header of a free + malloc chunk, and increase its size to make it overlap with other, + already-allocated malloc chunks. + +- Last, we allocate this enlarged malloc chunk, and use it to overwrite + large parts of the heap (the already-allocated malloc chunks) with + arbitrary data: + + . we overwrite the "id" string: it is used to build the message-log + file name, and therefore allows us to write to "/etc/passwd" (by + overwriting "id" with "/../../../../../../../../etc/passwd"); + + . we overwrite the "sender_address" string: it is written to the + message-log file, and therefore allows us to add a new user to + "/etc/passwd". + +Other exploitation methods may exist. We will not publish our exploit: +it is a quick and dirty proof of concept, and we will not have the time +to clean it anytime soon. However, please feel free to quote us on the +exploitability of this bug (we do have a working exploit), and please +feel free to quote all or parts of this email in your announcements. + +We are at your disposal for questions, comments, and further +discussions. Thank you very much! With best regards, + +-- +the Qualys Security Advisory team |