最近sudo发现了一个严重的缓存溢出提权漏洞CVE-2021-3156，这很正常。不正常的是这个漏洞已经潜伏了10年之久，为什么10年才发现呢？如果用常规的测试方法需要多久才能发现？对此有人进行了Fuzz测试，请和虫虫一起学习一下过程。

概述

在本文试验中，使用了AFL模糊器。AFL模糊器（American Fuzzy lop）是一种面向安全的模糊器，AFL使用新型编译时检测和遗传算法，自动发现干净有趣的测试用例，这些用例会在目标二进制文件中触发新的内部状态。用这样的方法可以大大改善了模糊代码的功能覆盖范围。

AFL模糊器生成的紧凑的合成语料库还可以用于复现其他测试人员更耗费人力或资源的测试方案。

测试准备

sudo是setuid二进制文件，以root用户随机输入运行潜在错误的二进制文件不是最安全的方法。为了避免任何潜在的意外系统损坏，此设置试验中使用了虚拟机环境。并选择最近一个涉及漏洞sudo版本sudo 1.9.5.p1。

AFL旨在将输出生成到文件或stdout中，但是要模糊命令行参数。因此，需要自行修补sudo，忽略实际的argv并将其改为从stdin。

AFL提供了一个可以提供这样功能的argv-fuzz-inl.h：

示例argv-fuzz-inl.h从stdin读取NUL分隔的参数。注意，sudo在单个二进制文件中同时提供了sudo和sudoedit实用程序，因此要测试两者，还需要向fuzzer公开argv[0]。输入的代码argv-fuzz-inl.h不会执行此操作，因此需要对其进行修复：

int rc = 0; /* start at argv[0] */

sudo本身补丁很简单，只需在main的开头连接AFL_INIT_ARGV即可：

--- a/src/sudo.c
+++ b/src/sudo.c
@@ -66,6 +66,8 @@
#include "sudo_plugin.h"
#include "sudo_plugin_int.h"

+#include "argv-fuzz-inl.h"
+
/*
* Local variables
*/
@@ -149,6 +151,7 @@ sudo_dso_public int main(int argc, char *argv[], char *envp[]);
int
main(int argc, char *argv[], char *envp[])
{
+AFL_INIT_ARGV();
int nargc, status = 0;
char **nargv, **env_add, **user_info;

快速测试表明sudo/sudoedit选择无法从stdin中传递的测试用例正常工作，因为出于某种原因，它使用了__progname。一个快速解决方法：

--- a/lib/util/progname.c
+++ b/lib/util/progname.c
@@ -83,7 +83,7 @@ void
initprogname2(const char *name, const char * const * allowed)
{
int i;
-# ifdef HAVE___PROGNAME
+# if 0
extern const char *__progname;

if (__progname != NULL && *__progname != '')

最后，设置无需等待密码输入，因此只需使其无条件失败即可：

--- a/plugins/sudoers/auth/sudo_auth.c
+++ b/plugins/sudoers/auth/sudo_auth.c
@@ -259,7 +259,7 @@ verify_user(struct passwd *pw, char *prompt, int validated,
"--disable-authentication configure option."));
debug_return_int(-1);
}
-
+return 0;
/* Enable suspend during password entry. */
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_RESTART;

由于某种原因afl-gcc工具无法正常工作，因此使用了基于LLVM的工具。需要重写CC为./configure：

CC=AFL-clang-fast ./configure

测试中使用了两个简单的测试用例，调用了两个可用的实用程序：

echo -ne 'sudols' > case1
echo -ne 'sudoedittest' > case2

准备就绪后，以并行模式启动了四个AFL实例。半小时后，出现了一个crash:

结果：

确实在sudoedit -s是崩溃了。假设并行运行了4个实例，大约2小时的CPU时间。通过2小时的CPU时间测试，就可以在setuid中找到严重的安全漏洞。

总结

为什么在十年中，才能发现这样的严重问题，其他重要的基础系统是否是不是也存在类似类似的潜伏漏洞。不知道之前有没有人对sudo做过模糊测试?或者社区大意了，只测试过sudo，而遗漏了不太引人注意的sudoedit了。

但是无论如何，需要指出的是，使用快速使用模糊测试程序可以发现广泛使用的实用程序中仍然存在严重的错误。