Adding upstream version 4.94.2.upstream/4.94.2upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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