这是内核漏洞挖掘技术系列的第一篇。
提到linux内核fuzz目前最流行的工具是syzkaller,不过在syzkaller出现之前(github上首次commit是2015年10月)linux内核fuzz用到最多的工具是trinity(github上首次commit是2006年3月,1.0版本发布于2012年8月),并且就在2019年1月刚刚发布了1.9版本(https://github.com/kernelslacker/trinity)。trinity网上也有各种二次开发的版本,有各种修改后在android下面跑的(https://bbs.pediy.com/thread-218969.htm),有用来fuzz perf_event_open系统调用的perf_fuzzer(https://github.com/deater/perf_event_tests)等等。比起来trinity算得上是元老级的fuzz工具了。本文会详细分析trinity目前最新的1.9版本的实现。
下面是《LCA: The Trinity fuzz tester》这篇文章中给的一张图。trinity-main执行各种初始化,然后创建执行系统调用的子进程。trinity-main创建的共享内存区域用于记录各种全局信息(打开文件描述符号、执行的系统调用总数以及成功和失败的系统调用数等等)和每个子进程的各种信息(pid和执行的系统调用信息等等)。trinity-watchdog确保系统正常工作。它会检查子进程是否正在运行(可能会在系统调用中被暂停),如果没有运行,则会将其杀死。当主进程检测到其中一个子进程已终止时(因为trinity-watchdog将其终止或出于其它原因)会启动一个新的子进程来替换它。trinity-watchdog还监视共享内存区域的完整性。(PS:《LCA: The Trinity fuzz tester》这篇文章是几年以前的了,根据后文的源码分析目前trinity-watchdog的功能已经被整合到trinity-main中)在trinity文件夹下除了子目录,还有下面这些源代码文件。
trinity文件夹下含有源代码文件的子目录如下。
下面我们从trinity.c的main函数开始分析。首先设置最大子进程数max_children为CPU核心数的4倍。然后处理参数,除了前面说到的还有几个比较有用的选项,比如-c表示fuzz指定的系统调用;-N表示指定fuzz的系统调用数量;-V接受目录参数,程序随机打开该目录中的文件,并将生成的文件描述符传递给系统调用,有助于发现特定文件系统类型中的漏洞等等。接下来创建并初始化共享内存区域。共享内存区域shm_s结构体定义在include\shm.h中,该结构体中的children是一个二维数组,数组中的每一个元素都是指向子进程使用的childdata结构体的指针。初始化系统调用,整体架构中已经提到了系统调用是通过include\syscallentry.h中的syscallentry结构体定义的,syscalltable结构体中的entry是一个指向syscallentry结构体的指针,所以通过指向syscalltable结构体的指针table通过table[i].entry可以取到所有的syscallentry。在include目录下arch-xxx.h定义了不同架构的syscalltable。比如当前操作系统是__x86_64__,那么include的是arch-x86-64.h。在arch-x86-64.h里面定义了当前同时使用64位和32位两种架构的系统调用。在syscallentry结构体中可以看到每个系统调用中包含系统调用名、参数个数、返回值类型和每一个参数的参数名、类型、取值范围等等。在初始化系统调用的过程中会调用它们的init函数。只有perf_event_open这个系统调用定义了相应的init函数。初始化文件描述符,整体架构中已经提到了objects.c管理系统调用中用到的文件描述符,每一种文件描述符具体的操作在fds文件夹中,都用fd_provider结构体表示,初始化时调用它们的open函数。还有其它的一些初始化操作,之后重点就在于main_loop函数,从main_loop函数退出以后执行一些清理善后的操作。在main_loop函数中首先记录下main函数已经开始,然后调用fork_children函数创建执行系统调用的子进程。在while循环中,只要子进程还在运行,就一直执行下面这些操作:1.首先在handle_children函数中等待子进程停止的信号。如果1秒之后没有接收到则返回。如果接收到则找到相应的子进程然后调用handle_child函数处理。在handle_child函数中如果子进程是正常终止则记录该子进程已经退出,删除它的所有有关引用,重新创建子进程;如果子进程是异常终止或者暂停则调用相应的处理函数handle_childsig,handle_childsig函数除了做一些记录,其它的处理和handle_child函数大致相同。2.检查内核是否taint,是则调用stop_ftrace函数停止ftrace并调用post-mortem.c中的tainted_postmortem函数,整体架构中已经提到了其功能是检测到taint之后向trinity-post-mortem.log写入每个子进程最后一个系统调用信息。3.检查共享内存区域是否损坏,是否持有共享内存区域的锁和每一个子进程使用的childdata结构体中的syscallrecord的锁。4.如果通过-N参数设定了fuzz系统调用的数量那么检查是否达到该数量。5.检查每一个子进程在进行最后一次系统调用之前记录的时间戳,记录进程是否处于僵尸状态。如果已经过去了30秒或者40秒及以上则发送SIGKILL信号杀死进程。如果所有的进程都处于僵尸状态,随机发送SIGKILL信号杀死进程。6.打印当前状态,如果正在运行的进程少于max_children则再创建进程。退出while循环之后如果共享内存区域没有损坏继续调用handle_children函数。如果还有子进程运行则杀死并记录下main函数已经结束。
下面我们重点来看子进程中的操作。前面我们已经知道了子进程是由fork_children函数创建的。在fork_children函数中调用了spawn_child函数。spawn_child函数中fork成功以后调用了child_process函数。在经过一些初始化操作以后,如果uid不为0,会调用到random_syscall函数。整体架构中已经提到了childops目录下的random-syscall.c中的random_syscall函数。random_syscall函数中首先随机选择一个系统调用。如果同时启用了64位的系统调用和32位的系统调用则有10%的几率选择32位的系统调用。如果该系统调用设置了AVOID_SYSCALL或者NI_SYSCALL标志的话还需要将其从active_syscall表中删除并重新选择。接下来生成函数参数。如果函数参数类型为ARG_UNDEFINED则随机生成一个数作为参数,对于其余的参数类型在generic_sanitise函数中调用fill_arg函数生成。在fill_arg函数中根据参数类型调用不同的函数生成对应的参数。比如参数是ARG_NON_NULL_ADDRESS类型(比如write函数的第二个参数),从初始化时sysv-shm.c创建的共享内存中找一块。再比如参数是ARG_SOCKETINFO类型(比如getsockname函数的第一个参数),从初始化文件描述符时创建的OBJ_FD_SOCKET中找一个。如果设置了EXTRA_FORK标志,在一个fork出的进程中执行系统调用。目前只有execveat和execve系统调用设置了这个标志,因为它们会将子进程替换掉。执行系统调用之后立即进行taint检测。如果系统调用返回值为-1说明调用失败,错误代码是ENOSYS(函数没有实现)则将其从active_syscall表中删除,对于其它的错误代码进行记录。否则说明调用成功,对于ARG_FD类型和ARG_LEN类型的参数进行记录。之后就是一些清理的工作。本文的分析就到此为止了。总的来说trinity还比较原始,不能自动生成复现的POC,函数参数类型有限,不支持代码覆盖率……如果有兴趣,也可以像前言中提到的那样做二次开发。以后会分享更多内核漏洞挖掘技术,争取写成一个系列。
1.LCA: The Trinity fuzz tester
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!
OxLucifer 要不要这么巧,我最近刚好也在学习trinity源码[em_4] 我还以为trinity这么多年没人提都不会有人再这类文章了[em_85]