Qualys Security Advisory 15 years later: Remote Code Execution in qmail (CVE-2005-1513) ======================================================================== Contents ======================================================================== Summary Analysis Exploitation qmail-verify - CVE-2020-3811 - CVE-2020-3812 Mitigations Acknowledgments Patches ======================================================================== Summary ======================================================================== TLDR: In 2005, three vulnerabilities were discovered in qmail but were never fixed because they were believed to be unexploitable in a default installation. We recently re-discovered these vulnerabilities and were able to exploit one of them remotely in a default installation. ------------------------------------------------------------------------ In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515): http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html): "This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits." Indeed, the memory consumption of each qmail-smtpd process is severely limited by default (by qmail-smtpd's startup script); for example, on Debian 10 (the latest stable release), it is limited to roughly 7MB. Unfortunately, we discovered that these vulnerabilities also affect qmail-local, which is reachable remotely and is not memory-limited by default (we investigated many qmail packages, and *all* of them limit qmail-smtpd's memory, but *none* of them limits qmail-local's memory). As a proof of concept, we developed a reliable, local and remote exploit against Debian's qmail package in its default configuration. This proof of concept requires 4GB of disk space and 8GB of memory, and allows an attacker to execute arbitrary shell commands as any user, except root (and a few system users who do not own their home directory). We will publish our proof-of-concept exploit in the near future. About our new discovery, Daniel J. Bernstein issues the following statement: "https://cr.yp.to/qmail/guarantee.html has for many years mentioned qmail's assumption that allocated array lengths fit comfortably into 32 bits. I run each qmail service under softlimit -m12345678, and I recommend the same for other installations." Finally, we also discovered two minor vulnerabilities in qmail-verify (a third-party qmail patch that is included in, for example, Debian's qmail package): CVE-2020-3811 (a mail-address verification bypass), and CVE-2020-3812 (a local information disclosure). ======================================================================== Analysis ======================================================================== We decided to exploit Georgi Guninski's vulnerability "1. integer overflow in stralloc_readyplus" (CVE-2005-1513). There are, in fact, four potential integer overflows in stralloc_readyplus; three in the GEN_ALLOC_readyplus() macro (which generates the stralloc_readyplus() function), at line 21 (n += x->len), line 23 (x->a = base + n + ...), and line 24 (x->a * sizeof(type)): ------------------------------------------------------------------------ 17 #define GEN_ALLOC_readyplus(ta,type,field,len,a,i,n,x,base,ta_rplus) \ 18 int ta_rplus(x,n) register ta *x; register unsigned int n; \ 19 { register unsigned int i; \ 20 if (x->field) { \ 21 i = x->a; n += x->len; \ 22 if (n > i) { \ 23 x->a = base + n + (n >> 3); \ 24 if (alloc_re(&x->field,i * sizeof(type),x->a * sizeof(type))) return 1; \ 25 x->a = i; return 0; } \ 26 return 1; } \ 27 x->len = 0; \ 28 return !!(x->field = (type *) alloc((x->a = n) * sizeof(type))); } ------------------------------------------------------------------------ and, in theory, one integer overflow in the alloc() function itself (which is called by the alloc_re() function), at line 18: ------------------------------------------------------------------------ 14 /*@null@*//*@out@*/char *alloc(n) 15 unsigned int n; 16 { 17 char *x; 18 n = ALIGNMENT + n - (n & (ALIGNMENT - 1)); /* XXX: could overflow */ .. 20 x = malloc(n); .. 22 return x; 23 } ------------------------------------------------------------------------ In practice, the integer overflows at line 21 (in GEN_ALLOC_readyplus()) and line 18 (in alloc()) are very hard to trigger; and the one at line 24 (in GEN_ALLOC_readyplus()) is irrelevant to stralloc_readyplus's case (because type is char and sizeof(type) is therefore 1). On the other hand, the integer overflow at line 23 (in GEN_ALLOC_readyplus()) is easy to trigger, because the size x->a of the buffer is increased by one eighth every time it is re-allocated: we send a very large mail message that contains a very long header line (nearly 4GB), and this line triggers stralloc_readyplus's integer overflow while in the getln() function, which is called by the bouncexf() function, at the beginning of the qmail-local program. qmail-local is responsible for the local delivery of mail messages, and runs with the privileges of the local recipient (or qmail's "alias" user, if the local recipient is "root", for example). After the size of the buffer is overflowed (at line 23), the alloc_re() function is called (at line 24), but with n < m, where n is the size of the new buffer y, and m is the size of the old buffer x: ------------------------------------------------------------------------ 4 int alloc_re(x,m,n) 5 char **x; 6 unsigned int m; 7 unsigned int n; 8 { 9 char *y; 10 11 y = alloc(n); 12 if (!y) return 0; 13 byte_copy(y,m,*x); 14 alloc_free(*x); 15 *x = y; 16 return 1; 17 } ------------------------------------------------------------------------ In other words, we transformed stralloc_readyplus's integer overflow into an mmap-based buffer overflow at line 13 (byte_copy() is qmail's version of memcpy()): m is nearly 4GB (the length of our very long header line), but n is roughly 512MB (one eighth of m). ======================================================================== Exploitation ======================================================================== To survive this large buffer overflow, we carefully choose the number and lengths of the very first lines in our mail message (they crucially influence the sequence of buffer re-allocations that eventually lead to the integer and buffer overflows), and obtain the following mmap layout: -------|-------|-------------------------------------------------|------ XXXXXXX| y | x | libc -------|-------|-------------------------------------------------|------ | 512MB | 4GB | Consequently, we safely overflow the new buffer y, and overwrite the malloc header of the old buffer x, with the contents of our very long header line. To exploit this malloc-header corruption when free(x) is called (at line 14), we devised an unusual method that bypasses NX and ASLR, but does not work against a full-RELRO binary (but the qmail-local binary on Debian 10 is partial-RELRO only). This does not mean, however, that a full-RELRO binary is not exploitable: other methods may exist, the only limit to malloc exploitation is the imagination. First, we overwrite the prev_size and size fields of x's malloc header, we set its IS_MMAPPED bit to 1, and therefore enter the munmap_chunk() function in __libc_free() (where p is a pointer to x's malloc header): ------------------------------------------------------------------------ 2810 static void 2811 munmap_chunk (mchunkptr p) 2812 { 2813 INTERNAL_SIZE_T size = chunksize (p); .... 2822 uintptr_t block = (uintptr_t) p - prev_size (p); 2823 size_t total_size = prev_size (p) + size; .... 2838 __munmap ((char *) block, total_size); 2839 } ------------------------------------------------------------------------ Because we completely control the size field (at line 2813) and the prev_size field (at lines 2822 and 2823), we completely control the block address (relative to p, and hence x) and the total_size of the __munmap() call (at line 2838). In other words, we can munmap() an arbitrary mmap region, without knowing the ASLR; we munmap() roughly 576MB at the end of x, including the first few pages of the libc: -------|-------|-----------------------------------------|-------+-|---- XXXXXXX| y | x |XXXXXXXXX|ibc -------|-------|-----------------------------------------|-------+-|---- The first pages of the libc do not actually contain executable code: they contain the ELF .dynsym section, which associates a symbol (for example, the "open" function) with the address of this symbol (relative to the start of the libc). Next, we end our very long header line (with a '\n' character), and start a new header line of nearly 576MB. This new header line is first written to the buffer y, but when y is full, stralloc_readyplus() allocates a new buffer t of roughly 576MB (the size of y plus one eighth), the exact size of the mmap region that we previously munmap()ed: -------|-------|-----------------------------------------|-------+-|---- XXXXXXX| y | x | t |ibc -------|-------|-----------------------------------------|-------+-|---- Consequently, we completely control the first pages of the libc (they contain the end of our new header line): we control the .dynsym section, and we replace the address of the "open" function with the address of the "system" function. This method works because Debian's qmail-local binary is partial-RELRO only, and because the open() function has not been called yet, and has therefore not been resolved yet. Last, we end our new header line, and when qmail-local returns from bouncexf() and calls qmesearch() to open() the ".qmail-extension" file, system(".qmail-extension") is called instead. Because we control this "extension" (it is an extension of the local recipient's mail address, for example localuser-extension@localdomain), we can execute arbitrary shell commands as any user (except root, and a few system users who do not own their home directory), by sending our large mail message to "localuser-;command;@localdomain". Last-minute note: the exploitation of glibc's free() to munmap() arbitrary memory regions has been discussed before, in http://tukan.farm/2016/07/27/munmap-madness/. ======================================================================== qmail-verify ======================================================================== ------------------------------------------------------------------------ CVE-2020-3811 ------------------------------------------------------------------------ Although the original qmail-smtpd does accept our recipient address "localuser-;command;@localdomain", Debian's qmail-smtpd should not, because it validates the recipient address with an external program qmail-verify (which should reject our recipient address, because the file "~localuser/.qmail-;command;" does not exist). Unfortunately, qmail-verify does reject "localuser-;command;@localdomain", but it accepts the unqualified "localuser-;command;" (without the @localdomain), because: - it never calls the control_init() function; - it therefore initializes its default domain to the hard-coded string "envnoathost"; - and accepts any unqualified mail address as valid by default (because its default domain "envnoathost" is not one of qmail's local domains, and is therefore unverifiable). ------------------------------------------------------------------------ CVE-2020-3812 ------------------------------------------------------------------------ We also discovered a minor information disclosure in qmail-verify: a local attacker can test for the existence of files and directories anywhere in the filesystem (even in inaccessible directories), because qmail-verify runs as root and tests for the existence of files in the attacker's home directory, without dropping its privileges first. For example (qmail-verify listens on 127.0.0.1:11113 by default): ------------------------------------------------------------------------ $ ls -l /root/.bashrc ls: cannot access '/root/.bashrc': Permission denied $ rm -f ~john/.qmail-test $ ln -s /root/.bashrc ~john/.qmail-test $ echo -n 'john-test@localdomain' | nc -w 2 -u 127.0.0.1 11113 | hexdump -C 00000000 a0 6a 6f 68 6e 2d 74 65 73 74 |.john-test| ------------------------------------------------------------------------ The least significant bit of this response's first byte (a0) is 0: the file "/root/.bashrc" exists. ------------------------------------------------------------------------ $ ls -l /root/.abcdef ls: cannot access '/root/.abcdef': Permission denied $ rm -f ~john/.qmail-test $ ln -s /root/.abcdef ~john/.qmail-test $ echo -n 'john-test@localdomain' | nc -w 2 -u 127.0.0.1 11113 | hexdump -C 00000000 e1 6a 6f 68 6e 2d 74 65 73 74 |.john-test| ------------------------------------------------------------------------ The least significant bit of this response's first byte (e1) is 1: the file "/root/.abcdef" does not exist. ======================================================================== Mitigations ======================================================================== As recommended by Daniel J. Bernstein, qmail can be protected against all three 2005 CVEs by placing a low, configurable memory limit (a "softlimit") in the startup scripts of all qmail services. Alternatively: qmail can be protected against the RCE (Remote Code Execution) by configuring the file "control/databytes", which contains the maximum size of a mail message (this file does not exist by default, and qmail is therefore remotely exploitable in its default configuration). Unfortunately, this does not protect qmail against the LPE (Local Privilege Escalation), because the file "control/databytes" is used exclusively by qmail-smtpd. ======================================================================== Acknowledgments ======================================================================== We thank Andrew Richards, Alexander Peslyak, the members of distros@openwall, and the developers of notqmail for their hard work on this coordinated release. We also thank Daniel J. Bernstein, and Georgi Guninski. Finally, we thank Julien Barthelemy, Stephane Bellenger, and Jean-Paul Michel for their inspiring work. ======================================================================== Patches ======================================================================== We wrote a simple patch for Debian's qmail package (below) that fixes CVE-2020-3811 and CVE-2020-3812 in qmail-verify, and fixes all three 2005 CVEs in qmail (by hard-coding a safe, upper memory limit in the alloc() function). Alternatively: - an updated version of qmail-verify will be available at https://free.acrconsulting.co.uk/email/qmail-verify.html after the Coordinated Release Date; - the developers of notqmail (https://notqmail.org/) have written their own patches for the three 2005 CVEs and have started to systematically fix all integer overflows and signedness errors in qmail. ------------------------------------------------------------------------ diff -r -u netqmail_1.06-6/alloc.c netqmail_1.06-6+patches/alloc.c --- netqmail_1.06-6/alloc.c 1998-06-15 03:53:16.000000000 -0700 +++ netqmail_1.06-6+patches/alloc.c 2020-05-04 16:43:32.923310325 -0700 @@ -1,3 +1,4 @@ +#include <limits.h> #include "alloc.h" #include "error.h" extern char *malloc(); @@ -15,6 +16,10 @@ unsigned int n; { char *x; + if (n >= (INT_MAX >> 3)) { + errno = error_nomem; + return 0; + } n = ALIGNMENT + n - (n & (ALIGNMENT - 1)); /* XXX: could overflow */ if (n <= avail) { avail -= n; return space + avail; } x = malloc(n); diff -r -u netqmail_1.06-6/qmail-verify.c netqmail_1.06-6+patches/qmail-verify.c --- netqmail_1.06-6/qmail-verify.c 2020-05-02 09:02:51.954415101 -0700 +++ netqmail_1.06-6+patches/qmail-verify.c 2020-05-08 04:47:27.555539058 -0700 @@ -16,6 +16,8 @@ #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> +#include <limits.h> +#include <grp.h> #include <pwd.h> #include <sys/socket.h> #include <netinet/in.h> @@ -38,6 +40,7 @@ #include "ip.h" #include "qmail-verify.h" #include "errbits.h" +#include "scan.h" #define enew() { eout("qmail-verify: "); } #define GETPW_USERLEN 32 @@ -71,6 +74,7 @@ void die_comms() { enew(); eout("Misc. comms problem: exiting.\n"); eflush(); _exit(1); } void die_inuse() { enew(); eout("Port already in use: exiting.\n"); eflush(); _exit(1); } void die_socket() { enew(); eout("Error setting up socket: exiting.\n"); eflush(); _exit(1); } +void die_privs() { enew(); eout("Unable to drop/restore privileges: exiting.\n"); eflush(); _exit(1); } char *posstr(buf,status) char *buf; int status; @@ -207,10 +211,47 @@ return 0; } +static int stat_as(uid, gid, path, sbuf) +const uid_t uid; +const gid_t gid; +const char * const path; +struct stat * const sbuf; +{ + static gid_t groups[NGROUPS_MAX + 1]; + int ngroups = 0; + const gid_t saved_egid = getegid(); + const uid_t saved_euid = geteuid(); + int ret = -1; + + if (saved_euid == 0) { + ngroups = getgroups(sizeof(groups) / sizeof(groups[0]), groups); + if (ngroups < 0 || + setgroups(1, &gid) != 0 || + setegid(gid) != 0 || + seteuid(uid) != 0) { + die_privs(); + } + } + + ret = stat(path, sbuf); + + if (saved_euid == 0) { + if (seteuid(saved_euid) != 0 || + setegid(saved_egid) != 0 || + setgroups(ngroups, groups) != 0) { + die_privs(); + } + } + + return ret; +} + int verifyaddr(addr) char *addr; { char *homedir; + uid_t uid = -1; + gid_t gid = -1; /* static since they get re-used on each call to verifyaddr(). Note that they don't need resetting since initial use is always with stralloc_copys() except wildchars (reset with ...len=0 below). */ @@ -303,6 +344,7 @@ if (r == 1) { char *x; + unsigned long u; if (!stralloc_ready(&nughde,(unsigned int) dlen)) die_nomem(); nughde.len = dlen; if (cdb_bread(fd,nughde.s,nughde.len) == -1) die_cdb(); @@ -318,10 +360,14 @@ if (x == nughde.s + nughde.len) return allowaddr(addr,ADDR_OK|QVPOS3); ++x; /* skip uid */ + scan_ulong(x,&u); + uid = u; x += byte_chr(x,nughde.s + nughde.len - x,'\0'); if (x == nughde.s + nughde.len) return allowaddr(addr,ADDR_OK|QVPOS4); ++x; /* skip gid */ + scan_ulong(x,&u); + gid = u; x += byte_chr(x,nughde.s + nughde.len - x,'\0'); if (x == nughde.s + nughde.len) return allowaddr(addr,ADDR_OK|QVPOS5); ++x; @@ -360,6 +406,8 @@ if (!stralloc_copys(&nughde,pw->pw_dir)) die_nomem(); if (!stralloc_0(&nughde)) die_nomem(); homedir=nughde.s; + uid = pw->pw_uid; + gid = pw->pw_gid; got_nughde: @@ -380,7 +428,7 @@ if (!stralloc_cat(&qme,&safeext)) die_nomem(); if (!stralloc_0(&qme)) die_nomem(); /* e.g. homedir/.qmail-localpart */ - if (stat(qme.s,&st) == 0) return allowaddr(addr,ADDR_OK|QVPOS10); + if (stat_as(uid,gid,qme.s,&st) == 0) return allowaddr(addr,ADDR_OK|QVPOS10); if (errno != error_noent) { return stat_error(qme.s,errno, STATERR|QVPOS11); /* Maybe not running as root so access denied */ } @@ -394,7 +442,7 @@ if (!stralloc_cats(&qme,"default")) die_nomem(); if (!stralloc_0(&qme)) die_nomem(); /* e.g. homedir/.qmail-[xxx-]default */ - if (stat(qme.s,&st) == 0) { + if (stat_as(uid,gid,qme.s,&st) == 0) { /* if it's ~alias/.qmail-default, optionally check aliases.cdb */ if (!i && (quser == auto_usera)) { char *s; @@ -423,6 +471,7 @@ char *s; if (chdir(auto_qmail) == -1) die_control(); + if (control_init() == -1) die_control(); if (control_rldef(&envnoathost,"control/envnoathost",1,"envnoathost") != 1) die_control(); [https://d1dejaj6dcqv24.cloudfront.net/asset/image/email-banner-384-2x.png]<https://www.qualys.com/email-banner> This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Qualys email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails (“spam”). If you have any concerns about this process, please contact us.