CodeQL漏洞挖掘实战

CodeQL是一个白盒源码审计工具，它以一种非常新颖的方式组织代码与元数据，使研究人员能够“像查询数据库一样检索代码”，并发现其中的安全问题。GitHub于去年收购了开发CodeQL的公司Semmel，并与其联合成立了GitHub Security Lab，Semmel在此前推出了面向开源社区和企业的源代码分析平台LGTM，这个平台能够自动化的发现并预警GitHub上开源软件的安全问题，同时，与CodeQL一样对开源社区与开发者保持免费。

本文将从CodeQL的基础知识出发，跟随GitHub Security Lab发布的互动式体验课程[1]，带领读者认识CodeQL在代码审计中的实际应用——在特定版本的uboot源码中发现多个安全问题，通过一段CodeQL查询语句定位到9个CVE漏洞。

一、CodeQL工作原理

CodeQL的整体工作流程[2][3]如下图所示：

CodeQL的查询需要建立在一个数据库的基础之上，这个数据库是通过Extractor模块对源代码进行分析、提取后得到的。数据库建立之后，我们就可以使用CodeQL去探索源码，并发现代码中的一些已知问题。

对于编译型语言，CodeQL会在建立数据库时“模拟”编译的过程，在make等编译工具链调用gcc等编译器时，用相同的编译参数调用extractor模块取而代之，收集源代码的所有相关信息，如AST抽象语法树、函数变量类型、预处理器操作等等。对于解释型语言，因为没有编译器的存在，CodeQL会以跟踪执行的方式获取类似的信息。

二、CodeQL使用

使用CodeQL CLI对代码仓库运行分析[4]后，我们就得到了一个“快照数据库”[5]（SnapshotDatabase），这个数据库中存储了代码仓库在特定时间点（数据库建立时）的层级表示方式，包括AST语法树、CFG控制流程关系和DFG数据流向关系。在这个数据库中，代码中的每一个要素，比如函数定义（Function）、函数调用（FunctionCall）、宏调用（MacroInvocation）都是可以被检索的实体。在这些基础上，我们再编写CodeQL语句对代码进行分析。

CodeQL环境的安装在这里不再赘述，在官方教程[6]与本文涉及的课程内容中[7]都有详细说明。在VSCode中导入数据库之后，我们就可以开始编写第一条CodeQL语句了。

三、基本语法

我们以字节序转换函数为例，查找uboot代码库中ntohs、ntohl、ntohll的定义。

从上面的代码段中我们可以看到，CodeQL遵循与SQL相似的基本语义：select ... from ... where ...。但不同的是CodeQL中又加入了面向对象的思想，比如m.getName()可以获取查询对象的名字，再调用另一个函数进行正则匹配获得我们最终需要的名称匹配逻辑表达式。本例CodeQL的运行输出如下图所示，表格中每一行的蓝色代码片段都可以点击跳转到uboot代码库中，相应宏的定义位置。

常用的几种查询对象类型：

• Function 函数定义、函数声明
• FunctionCall 函数调用
• Macro 宏定义
• MacroInvocation 宏调用
• Expr 表达式
• AssignExpr 赋值表达式（是Expr的子集）
• ConditionalStmt 条件表达式

通过上面的方式，我们可以使用CodeQL对代码中的基本单元进行查询检索。更进一步，我们可以定义class将复杂的判断条件进行封装，输出更精确的结果。

我们对上一个例子中宏调用的查询进行延申，通过定义一个NetworkByteSwap类，这个类代表符合“某些特征”的表达式的全集，在本例中，我们限定我们需要的是包含ntohs、ntohl宏调用的表达式，并通过from n select n的方式将它们简单的列举出来

以上CodeQL语句的输出如下图所示。

我们点击返回的第1条结果，可以看到编辑器会跳转到表达式所在的文件，并将整条表达式选中高亮起来，非常直观。

学到现在，我们就可以用CodeQL来尝试一下挖漏洞了！

回忆上一步，我们定义了一个NetworkByteSwap类，用于筛选出调用ntohs的表达式。接下来，我们引入CodeQL中的污点跟踪模块，指定这些表达式为污点源（source），并设置数据汇聚点为memcpy的第3个参数。根据Linux的manpage[8]，memcpy函数的第3个参数是待复制数据块的长度，因为ntohs是进制转换的函数，因此通过ntohs输入的数据很有可能是用户可控的参数值，通过这条路径传递给memcpy，就能转化为用户可控的内存操作。这就是漏洞的根源。将这个数据流关系转化为CodeQL代码如下。

我们只在上一个例子的基础上增加了约20行代码，运行之后，得到9条结果，根据课程介绍[9]，此时应该可以得到9个CVE漏洞了。但笔者才疏学浅，根据CVE漏洞库中的描述，粗略统计过后，能直观看出的漏洞点的CVE漏洞有6个，各位读者可以自行尝试。

这就是整个U-Boot Challenge课程的尾声，用40行的代码，挖出了一箩筐CVE漏洞。

四、结语

代码审计并不是什么新兴领域，业界、学术界我们都能找到很多成熟的工具，如Fortify SCA、RIPS、Coverity等等，商业软件如Fortify提供了非常完善的规则库，它们能够快速、自动化的发现通用型的安全问题。而CodeQL更接近于一个分析框架，它赋能研究人员对审计目标进行更为复杂的安全建模，但同时也更依赖研究者对审计目标、底层技术有更为深入的理解。简单的漏洞可以靠工具发现，更复杂的漏洞就需要靠人去挖掘了。CodeQL作为一个分析框架，在专家经验的加持下，才能够发挥其最大的功效，这是它的缺点，但它作为一个框架，能够提供丰富的API和简洁的语义使研究者能够快速验证分析思路、发现特定场景产生的漏洞，这种高度自由也是其不可忽视的优点。