1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
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
|
