From e90fcc54809db2591dc083f43ef54c6ec8c60847 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 18:16:13 +0200 Subject: Adding upstream version 4.96. Signed-off-by: Daniel Baumann --- doc/cve-2019-15846/qualys.mbx | 175 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 doc/cve-2019-15846/qualys.mbx (limited to 'doc/cve-2019-15846/qualys.mbx') 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 +To: Heiko Schlittermann +Subject: Re: Help evaluating a Bug in Exim MTA +Return-Path: +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 +To: Heiko Schlittermann +Subject: Re: Help evaluating a Bug in Exim MTA +Return-Path: +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 -- cgit v1.2.3