1 files changed, 175 insertions, 0 deletions
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