| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20210126181908.GB4184@localhost.localdomain>
Date: Tue, 26 Jan 2021 18:20:05 +0000
From: Qualys Security Advisory <qsa@...lys.com>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: [FD] Baron Samedit: Heap-based buffer overflow in Sudo
(CVE-2021-3156)
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@...ry=0x7f6e0d9cc020 "sudoers", msgid1=msgid1@...ry=0x7f6e0d9cc014 "user NOT in sudoers", msgid2=msgid2@...ry=0x0, plural=plural@...ry=0, n=n@...ry=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@...ry=0x7f4a6d7dc046 "SYSTEMD_BYPASS_USERDB", value=value@...ry=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@...BC_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@...ry=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@...nwall.
========================================================================
Timeline
========================================================================
2021-01-13: Advisory sent to Todd.Miller@...o.
2021-01-19: Advisory and patches sent to distros@...nwall.
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.
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
Powered by blists - more mailing lists