Sudo Heap-Based Buffer Overflow

#244
Topic created · 1 Posts · 0 Views
  • Qualys has released extensive research details regarding a heap-based buffer overflow vulnerability in sudo. The issue was introduced in July 2011 (commit 8255ed69)
    , and affects all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1, in their default configuration.
    MD5 | 0c2a538435159ba2390cd0a028f6de4c
    Download

    Qualys Security Advisory  
    Baron Samedit: Heap-based buffer overflow in Sudo (CVE-2021-3156)  
    ========================================================================  
    Contents  
    ========================================================================  
    Summary  
    Analysis  
    Exploitation  
    Acknowledgments  
    Timeline  
    ========================================================================  
    Summary  
    ========================================================================  
    We discovered a heap-based buffer overflow in Sudo  
    (https://www.sudo.ws/). This vulnerability:  
    - is exploitable by any local user (normal users and system users,  
    sudoers and non-sudoers), without authentication (i.e., the attacker  
    does not need to know the user's password);  
    - was introduced in July 2011 (commit 8255ed69), and affects all legacy  
    versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to  
    1.9.5p1, in their default configuration.  
    We developed three different exploits for this vulnerability, and  
    obtained full root privileges on Ubuntu 20.04 (Sudo 1.8.31), Debian 10  
    (Sudo 1.8.27), and Fedora 33 (Sudo 1.9.2). Other operating systems and  
    distributions are probably also exploitable.  
    ========================================================================  
    Analysis  
    ========================================================================  
    If Sudo is executed to run a command in "shell" mode (shell -c command):  
    - either through the -s option, which sets Sudo's MODE_SHELL flag;  
    - or through the -i option, which sets Sudo's MODE_SHELL and  
    MODE_LOGIN_SHELL flags;  
    then, at the beginning of Sudo's main(), parse_args() rewrites argv  
    (lines 609-617), by concatenating all command-line arguments (lines  
    587-595) and by escaping all meta-characters with backslashes (lines  
    590-591):  
    ------------------------------------------------------------------------  
    571     if (ISSET(mode, MODE_RUN) && ISSET(flags, MODE_SHELL)) {  
    572         char **av, *cmnd = NULL;  
    573         int ac = 1;  
    ...  
    581             cmnd = dst = reallocarray(NULL, cmnd_size, 2);  
    ...  
    587             for (av = argv; *av != NULL; av++) {  
    588                 for (src = *av; *src != '\0'; src++) {  
    589                     /* quote potential meta characters */  
    590                     if (!isalnum((unsigned char)*src) && *src != '_' && *src != '-' && *src != '$')  
    591                         *dst++ = '\\';  
    592                     *dst++ = *src;  
    593                 }  
    594                 *dst++ = ' ';  
    595             }  
    ...  
    600             ac += 2; /* -c cmnd */  
    ...  
    603         av = reallocarray(NULL, ac + 1, sizeof(char *));  
    ...  
    609         av[0] = (char *)user_details.shell; /* plugin may override shell */  
    610         if (cmnd != NULL) {  
    611             av[1] = "-c";  
    612             av[2] = cmnd;  
    613         }  
    614         av[ac] = NULL;  
    615  
    616         argv = av;  
    617         argc = ac;  
    618     }  
    ------------------------------------------------------------------------  
    Later, in sudoers_policy_main(), set_cmnd() concatenates the  
    command-line arguments into a heap-based buffer "user_args" (lines  
    864-871) and unescapes the meta-characters (lines 866-867), "for sudoers  
    matching and logging purposes":  
    ------------------------------------------------------------------------  
    819     if (sudo_mode & (MODE_RUN | MODE_EDIT | MODE_CHECK)) {  
    ...  
    852             for (size = 0, av = NewArgv + 1; *av; av++)  
    853                 size += strlen(*av) + 1;  
    854             if (size == 0 || (user_args = malloc(size)) == NULL) {  
    ...  
    857             }  
    858             if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) {  
    ...  
    864                 for (to = user_args, av = NewArgv + 1; (from = *av); av++) {  
    865                     while (*from) {  
    866                         if (from[0] == '\\' && !isspace((unsigned char)from[1]))  
    867                             from++;  
    868                         *to++ = *from++;  
    869                     }  
    870                     *to++ = ' ';  
    871                 }  
    ...  
    884             }  
    ...  
    886     }  
    ------------------------------------------------------------------------  
    Unfortunately, if a command-line argument ends with a single backslash  
    character, then:  
    - at line 866, "from[0]" is the backslash character, and "from[1]" is  
    the argument's null terminator (i.e., not a space character);  
    - at line 867, "from" is incremented and points to the null terminator;  
    - at line 868, the null terminator is copied to the "user_args" buffer,  
    and "from" is incremented again and points to the first character  
    after the null terminator (i.e., out of the argument's bounds);  
    - the "while" loop at lines 865-869 reads and copies out-of-bounds  
    characters to the "user_args" buffer.  
    In other words, set_cmnd() is vulnerable to a heap-based buffer  
    overflow, because the out-of-bounds characters that are copied to the  
    "user_args" buffer were not included in its size (calculated at lines  
    852-853).  
    In theory, however, no command-line argument can end with a single  
    backslash character: if MODE_SHELL or MODE_LOGIN_SHELL is set (line 858,  
    a necessary condition for reaching the vulnerable code), then MODE_SHELL  
    is set (line 571) and parse_args() already escaped all meta-characters,  
    including backslashes (i.e., it escaped every single backslash with a  
    second backslash).  
    In practice, however, the vulnerable code in set_cmnd() and the escape  
    code in parse_args() are surrounded by slightly different conditions:  
    ------------------------------------------------------------------------  
    819     if (sudo_mode & (MODE_RUN | MODE_EDIT | MODE_CHECK)) {  
    ...  
    858             if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) {  
    ------------------------------------------------------------------------  
    versus:  
    ------------------------------------------------------------------------  
    571     if (ISSET(mode, MODE_RUN) && ISSET(flags, MODE_SHELL)) {  
    ------------------------------------------------------------------------  
    Our question, then, is: can we set MODE_SHELL and either MODE_EDIT or  
    MODE_CHECK (to reach the vulnerable code) but not the default MODE_RUN  
    (to avoid the escape code)?  
    The answer, it seems, is no: if we set MODE_EDIT (-e option, line 361)  
    or MODE_CHECK (-l option, lines 423 and 519), then parse_args() removes  
    MODE_SHELL from the "valid_flags" (lines 363 and 424) and exits with an  
    error if we specify an invalid flag such as MODE_SHELL (lines 532-533):  
    ------------------------------------------------------------------------  
    358                 case 'e':  
    ...  
    361                     mode = MODE_EDIT;  
    362                     sudo_settings[ARG_SUDOEDIT].value = "true";  
    363                     valid_flags = MODE_NONINTERACTIVE;  
    364                     break;  
    ...  
    416                 case 'l':  
    ...  
    423                     mode = MODE_LIST;  
    424                     valid_flags = MODE_NONINTERACTIVE|MODE_LONG_LIST;  
    425                     break;  
    ...  
    518     if (argc > 0 && mode == MODE_LIST)  
    519         mode = MODE_CHECK;  
    ...  
    532     if ((flags & valid_flags) != flags)  
    533         usage(1);  
    ------------------------------------------------------------------------  
    But we found a loophole: if we execute Sudo as "sudoedit" instead of  
    "sudo", then parse_args() automatically sets MODE_EDIT (line 270) but  
    does not reset "valid_flags", and the "valid_flags" include MODE_SHELL  
    by default (lines 127 and 249):  
    ------------------------------------------------------------------------  
    127 #define DEFAULT_VALID_FLAGS     (MODE_BACKGROUND|MODE_PRESERVE_ENV|MODE_RESET_HOME|MODE_LOGIN_SHELL|MODE_NONINTERACTIVE|MODE_SHELL)  
    ...  
    249     int valid_flags = DEFAULT_VALID_FLAGS;  
    ...  
    267     proglen = strlen(progname);  
    268     if (proglen > 4 && strcmp(progname + proglen - 4, "edit") == 0) {  
    269         progname = "sudoedit";  
    270         mode = MODE_EDIT;  
    271         sudo_settings[ARG_SUDOEDIT].value = "true";  
    272     }  
    ------------------------------------------------------------------------  
    Consequently, if we execute "sudoedit -s", then we set both MODE_EDIT  
    and MODE_SHELL (but not MODE_RUN), we avoid the escape code, reach the  
    vulnerable code, and overflow the heap-based buffer "user_args" through  
    a command-line argument that ends with a single backslash character:  
    ------------------------------------------------------------------------  
    sudoedit -s '\' `perl -e 'print "A" x 65536'`  
    malloc(): corrupted top size  
    Aborted (core dumped)  
    ------------------------------------------------------------------------  
    From an attacker's point of view, this buffer overflow is ideal:  
    - we control the size of the "user_args" buffer that we overflow (the  
    size of our concatenated command-line arguments, at lines 852-854);  
    - we independently control the size and contents of the overflow itself  
    (our last command-line argument is conveniently followed by our first  
    environment variables, which are not included in the size calculation  
    at lines 852-853);  
    - we can even write null bytes to the buffer that we overflow (every  
    command-line argument or environment variable that ends with a single  
    backslash writes a null byte to "user_args", at lines 866-868).  
    For example, on an amd64 Linux, the following command allocates a  
    24-byte "user_args" buffer (a 32-byte heap chunk) and overwrites the  
    next chunk's size field with "A=a\0B=b\0" (0x00623d4200613d41), its fd  
    field with "C=c\0D=d\0" (0x00643d4400633d43), and its bk field with  
    "E=e\0F=f\0" (0x00663d4600653d45):  
    ------------------------------------------------------------------------  
    env -i 'AA=a\' 'B=b\' 'C=c\' 'D=d\' 'E=e\' 'F=f' sudoedit -s '1234567890123456789012\'  
    ------------------------------------------------------------------------  
    --|--------+--------+--------+--------|--------+--------+--------+--------+--  
    |        |        |12345678|90123456|789012.A|A=a.B=b.|C=c.D=d.|E=e.F=f.|  
    --|--------+--------+--------+--------|--------+--------+--------+--------+--  
    size  <---- user_args buffer ---->  size      fd       bk  
    ========================================================================  
    Exploitation  
    ========================================================================  
    Because Sudo calls localization functions at the very beginning of its  
    main() function:  
    ------------------------------------------------------------------------  
    154     setlocale(LC_ALL, "");  
    155     bindtextdomain(PACKAGE_NAME, LOCALEDIR);  
    156     textdomain(PACKAGE_NAME);  
    ------------------------------------------------------------------------  
    and passes translation strings (through the gettext() function and _()  
    macro) to format-string functions such as:  
    ------------------------------------------------------------------------  
    301             sudo_printf(SUDO_CONV_ERROR_MSG, _("%s is not in the sudoers "  
    302                 "file.  This incident will be reported.\n"), user_name);  
    ------------------------------------------------------------------------  
    we initially wanted to reuse halfdog's fascinating technique from  
    https://www.halfdog.net/Security/2017/LibcRealpathBufferUnderflow/ and  
    transform Sudo's heap-based buffer overflow into a format-string  
    exploit. More precisely:  
    - at line 154, in setlocale(), we malloc()ate and free() several LC  
    environment variables (LC_CTYPE, LC_MESSAGES, LC_TIME, etc), thereby  
    creating small holes at the very beginning of Sudo's heap (free fast  
    or tcache chunks);  
    - at line 155, bindtextdomain() malloc()ates a struct binding, which  
    contains a dirname pointer to the name of a directory that contains  
    ".mo" catalog files and hence translation strings;  
    - in set_cmnd(), we malloc()ate the "user_args" buffer into one of the  
    holes at the beginning of Sudo's heap, and overflow this buffer, thus  
    overwriting the struct binding's dirname pointer;  
    - at line 301 (for example), gettext() (through the _() macro) loads our  
    own translation string from the overwritten dirname -- in other words,  
    we control the format string that is passed to sudo_printf().  
    To implement this initial technique, we wrote a rudimentary brute-forcer  
    that executes Sudo inside gdb, overflows the "user_args" buffer, and  
    randomly selects the following parameters:  
    - the LC environment variables that we pass to Sudo, and their length  
    (we use the "C.UTF-8" locale and append a random "@modifier");  
    - the size of the "user_args" buffer that we overflow;  
    - the size of the overflow itself;  
    - whether we go through Sudo's authentication code (-A or -n option) or  
    not (-u #realuid option).  
    Unfortunately, this initial technique failed; our brute-forcer was able  
    to overwrite the struct binding's dirname pointer:  
    ------------------------------------------------------------------------  
    Program received signal SIGSEGV, Segmentation fault.  
    0x00007f6e0dde1ea9 in __dcigettext ([[email protected]](/cdn-cgi/l/email-protection)=0x7f6e0d9cc020 "sudoers", [[email protected]](/cdn-cgi/l/email-protection)=0x7f6e0d9cc014 "user NOT in sudoers", [[email protected]](/cdn-cgi/l/email-protection)=0x0, [[email protected]](/cdn-cgi/l/email-protection)=0, [[email protected]](/cdn-cgi/l/email-protection)=0, category=5) at dcigettext.c:619  
    => 0x7f6e0dde1ea9 <__dcigettext+1257>:  cmpb   $0x2f,(%rax)  
    rax            0x4141414141414141  4702111234474983745  
    ------------------------------------------------------------------------  
    but LC_MESSAGES was always the default "C" locale (not "C.UTF-8"), which  
    disables the string translation in gettext() (i.e., gettext() returns  
    the original format string, not our own).  
    Fortunately, however, our brute-forcer produced dozens of unique Sudo  
    crashes and gdb backtraces; among these, three caught our attention, and  
    we eventually exploited all three.  
    ========================================================================  
    1/ struct sudo_hook_entry overwrite  
    ========================================================================  
    The first crash that caught our attention is:  
    ------------------------------------------------------------------------  
    Program received signal SIGSEGV, Segmentation fault.  
    0x000056291a25d502 in process_hooks_getenv ([[email protected]](/cdn-cgi/l/email-protection)=0x7f4a6d7dc046 "SYSTEMD_BYPASS_USERDB", [[email protected]](/cdn-cgi/l/email-protection)=0x7ffc595cc240) at ../../src/hooks.c:108  
    => 0x56291a25d502 <process_hooks_getenv+82>:    callq  *0x8(%rbx)  
    rbx            0x56291c1df2b0      94734565372592  
    0x56291c1df2b0: 0x4141414141414141      0x4141414141414141  
    ------------------------------------------------------------------------  
    Incredibly, Sudo's function process_hooks_getenv() crashed (at line 108)  
    because we directly overwrote a function pointer, getenv_fn (a member of  
    a heap-based struct sudo_hook_entry):  
    ------------------------------------------------------------------------  
    99 int  
    100 process_hooks_getenv(const char *name, char **value)  
    101 {  
    102     struct sudo_hook_entry *hook;  
    103     char *val = NULL;  
    ...  
    107     SLIST_FOREACH(hook, &sudo_hook_getenv_list, entries) {  
    108         rc = hook

    u.getenv_fn(name, &val, hook

    closure); ------------------------------------------------------------------------ To exploit this struct sudo_hook_entry overwrite, we note that: - the call to getenv_fn (at line 108) is compatible with a call to execve(): . name ("SYSTEMD_BYPASS_USERDB") is compatible with execve()'s pathname argument; . &val (a pointer to a NULL pointer) is compatible with execve()'s argv; . hook->closure (a NULL pointer) is compatible with execve()'s envp; - we can defeat ASLR by partially overwriting the function pointer getenv_fn (which points to the function sudoers_hook_getenv() in the shared library sudoers.so); and luckily, the beginning of sudoers.so contains a call to execve() (or execv()): ------------------------------------------------------------------------ 0000000000008a00 <[[email protected]](/cdn-cgi/l/email-protection)>: 8a00: f3 0f 1e fa endbr64 8a04: f2 ff 25 65 55 05 00 bnd jmpq *0x55565(%rip) # 5df70 <[[email protected]](/cdn-cgi/l/email-protection)_2.2.5> 8a0b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) ------------------------------------------------------------------------ - we can read /dev/kmsg (dmesg) as an unprivileged user on Ubuntu, and therefore obtain detailed information about our Sudo crashes. Consequently, we adopt the following strategy: - First, we brute-force the exploit parameters until we overwrite getenv_fn with an invalid userland address (above 0x800000000000) -- until we observe a general protection fault at getenv_fn's call site: ------------------------------------------------------------------------ sudoedit[15904] general protection fault ip:55e9b645b502 sp:7ffe53d6fa40 error:0 in sudo[55e9b644e000+1a000] ^^^ ------------------------------------------------------------------------ - Next, we reuse these exploit parameters but overwrite getenv_fn with a regular pattern of valid (below 0x800000000000) but unmapped userland addresses -- in this example, getenv_fn is the 22nd pointer that we overwrite (0x32 is '2', a part of our pattern): ------------------------------------------------------------------------ sudoedit[15906]: segfault at 323230303030 ip 0000323230303030 sp 00007ffeeabf2868 error 14 in sudo[55b036c16000+5000] ^^^^ ------------------------------------------------------------------------ - Last, we partially overwrite getenv_fn (we overwrite its two least significant bytes with 0x8a00, execv()'s offset in sudoers.so, and its third byte with 0x00, user_args's null terminator in set_cmnd()) until we defeat ASLR -- we have a good chance of overwriting getenv_fn with the address of execv() after 2^(3*8-12) = 2^12 = 4096 tries, thus executing our own binary, named "SYSTEMD_BYPASS_USERDB", as root. We successfully tested this first exploit on Ubuntu 20.04. ======================================================================== 2/ struct service_user overwrite ======================================================================== The second crash that caught our attention is: ------------------------------------------------------------------------ Program received signal SIGSEGV, Segmentation fault. 0x00007f6bf9c294ee in nss_load_library ([[email protected]](/cdn-cgi/l/email-protection)=0x55cf1a1dd040) at nsswitch.c:344 => 0x7f6bf9c294ee <nss_load_library+46>: cmpq $0x0,0x8(%rbx) rbx 0x41414141414141 18367622009667905 ------------------------------------------------------------------------ The glibc's function nss_load_library() crashed (at line 344) because we overwrote the pointer "library", a member of a heap-based struct service_user: ------------------------------------------------------------------------ 327 static int 328 nss_load_library (service_user *ni) 329 { 330 if (ni->library == NULL) 331 { ... 338 ni->library = nss_new_service (service_table ?: &default_table, 339 ni->name); ... 342 } 343 344 if (ni

    library

    lib_handle == NULL) 345 { 346 /* Load the shared library. */ 347 size_t shlen = (7 + strlen (ni->name) + 3 348 + strlen (__nss_shlib_revision) + 1); 349 int saved_errno = errno; 350 char shlib_name[shlen]; 351 352 /* Construct shared object name. */ 353 __stpcpy (__stpcpy (__stpcpy (__stpcpy (shlib_name, 354 "libnss_"), 355 ni->name), 356 ".so"), 357 __nss_shlib_revision); 358 359 ni

    library

    lib_handle = __libc_dlopen (shlib_name); ------------------------------------------------------------------------ We can easily transform this struct service_user overwrite into an arbitrary code execution: - we overwrite ni->library with a NULL pointer, to enter the block at lines 330-342, avoid the crash at line 344, and enter the block at lines 344-359; - we overwrite ni->name (an array of characters, initially "systemd") with "X/X"; - lines 353-357 construct the name of a shared library "libnss_X/X.so.2" (instead of "libnss_systemd.so.2"); - at line 359, we load our own shared library "libnss_X/X.so.2" from the current working directory and execute our _init() constructor as root. We successfully tested this second exploit on Ubuntu 20.04, Debian 10, and Fedora 33. ======================================================================== 3/ def_timestampdir overwrite ======================================================================== Our third exploit is not derived from one of Sudo's crashes, but from a casual observation: during our brute-force, Sudo created dozens of new directories in our current working directory (AAAAAA, AAAAAAAAA, etc). Each of these directories belongs to root and contains only one small file, named after our own user: Sudo's timestamp file -- we evidently overwrote def_timestampdir, the name of Sudo's timestamp directory. If we overwrite def_timestampdir with the name of a directory that does not already exist, then we can race against Sudo's ts_mkdirs(), create a symlink to an arbitrary file, and: 3a/ either chown() this arbitrary file to user root and group root; 3b/ or open (or create) this arbitrary file as root, and write a struct timestamp_entry to it. We were unable to transform 3a/ into full root privileges (for example, if we chown() our own SUID binary to root, then the kernel automatically removes our binary's SUID bit). If you, dear reader, find a solution to this problem, please post it to the public oss-security mailing list! Eventually, we were able to transform 3b/ into full root privileges, but we initially faced two problems: - Sudo's timestamp_open() deletes our arbitrary symlink if the file it points to is older than boot time. We were able to solve this first problem by creating a very old timestamp file (from the Unix epoch), by waiting until timestamp_open() deletes it, and by racing against timestamp_open() to create our final, arbitrary symlink. - We do not control the contents of the struct timestamp_entry that is written to the arbitrary file. To the best of our knowledge, we only control three bytes (a process ID or a struct timespec), and we were unable to transform this three-byte write into full root privileges. If you, dear reader, find a solution to this problem, please post it to the public oss-security mailing list! However, we were able to circumvent this second problem by abusing a minor bug in Sudo's timestamp_lock(). If we win the two races against ts_mkdirs() and timestamp_open(), and if our arbitrary symlink points to /etc/passwd, then this file is opened as root, and: ------------------------------------------------------------------------ 65 struct timestamp_entry { 66 unsigned short version; /* version number */ 67 unsigned short size; /* entry size */ 68 unsigned short type; /* TS_GLOBAL, TS_TTY, TS_PPID */ .. 78 }; ------------------------------------------------------------------------ 305 static ssize_t 306 ts_write(int fd, const char *fname, struct timestamp_entry *entry, off_t offset) 307 { ... 318 nwritten = pwrite(fd, entry, entry->size, offset); ... 350 } ------------------------------------------------------------------------ 619 bool 620 timestamp_lock(void *vcookie, struct passwd *pw) 621 { 622 struct ts_cookie *cookie = vcookie; 623 struct timestamp_entry entry; ... 644 nread = read(cookie->fd, &entry, sizeof(entry)); 645 if (nread == 0) { ... 652 } else if (entry.type != TS_LOCKEXCL) { ... 657 if (ts_write(cookie

    fd, cookie

    fname, &entry, 0) == -1) ------------------------------------------------------------------------ - at line 644, the first 0x38 bytes of /etc/passwd ("root:x:0:0:...") are read into a stack-based struct timestamp_entry, entry; - at line 652, entry.type is 0x783a (":x"), not TS_LOCKEXCL; - at lines 657 and 318, entry->size bytes from the stack-based entry are written to /etc/passwd, but entry->size is actually 0x746f ("ot"), not sizeof(struct timestamp_entry). As a result, we write the entire contents of Sudo's stack to /etc/passwd (including our command-line arguments and our environment variables): we inject an arbitrary user into /etc/passwd and therefore obtain full root privileges. We successfully tested this third exploit on Ubuntu 20.04. Note: this minor bug in timestamp_lock() was fixed in January 2020 by commit 586b418a, but this fix was not backported to legacy versions. ======================================================================== Acknowledgments ======================================================================== We thank Todd C. Miller for his professionalism, quick response, and meticulous attention to every detail in our report. We also thank the members of [[email protected]](/cdn-cgi/l/email-protection) ======================================================================== Timeline ======================================================================== 2021-01-13: Advisory sent to [[email protected]](/cdn-cgi/l/email-protection) 2021-01-19: Advisory and patches sent to [[email protected]](/cdn-cgi/l/email-protection) 2021-01-26: Coordinated Release Date (6:00 PM UTC). [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.

    Source: packetstormsecurity.com

Log in to reply