使用doop识别最近commons text漏洞的污点信息流

借用网上公开的poc触发StringLookup中的代码执行，使用commons text 1.9版本 ：

完整的漏洞调用栈如下：

从调用栈可以看出，通过调用commons text的字符串替换函数，可以调用到StringLookup类的lookup方法，从而调用Engine.eval执行代码。可以看出该条漏洞链路较浅，但链路关键节点也涉及了接口抽象类的cast、输入字符串的词法分析状态机以及各种字符串的处理函数，作为实验对象非常合适。

我们选取上述二中commons text中

org.apache.commons.text.StringSubstitutor replace函数作为source，Engine eval函数作为sink。

doop设置app only模式去进行分析，doop在app only模式下会将!ApplicationMethod(?signature)加入isOpaqueMethod(?signature)，这样一些分析不会进入jdk的类中，可以大大提高doop的分析效率。依据莱斯定理，静态程序分析难以达到完全的完备(truth或者perfect)，也是尽可能优化sound。类似在企业级的SAST部署使用也是如此，也需要在扫描精度、扫描速度以及实际可用性中进行取舍或者平衡，所以doop的app only模式下在个人看来更接近实际嵌入到devsecops中的轻量级静态代码漏洞扫描的应用。

3.1 doop的datalog分析规则简单介绍

由于涉及doop app only规则的改造，首先先简单介绍doop使用的datalog规则。

doop目前维护使用开源的Soufflé分析datalog规则。datalog是声明式的编程语言，也是prolog语言的非图灵完备子集，所以本质上也是建立在形式逻辑中的一阶逻辑上。所以基础概念也是命题推导，在Soufflé的形式上就是表现为关系（relation）。

如下例子：

很明显可以看出该例子通过datalog定义的关系逻辑实现相等关系的自反性、对称性和传递性，首先定义了equivalence关系，该关系可以由rel1和rel2关系蕴涵得到，而equivalence的a需要满足关系rel1，b需要满足关系rel2。具体语法和高阶特性可以通过souffle-lang.github.io网站进行了解。

3.2 doop配置使用简单介绍

doop可以通过gradle去编译使用，需要提前在类unix系统中借助cmake编译安装Soufflé，doop的具体安装使用可以在https://github.com/plast-lab/doop-mirror中了解。

对doop的命令行使用进行简单，分析，有几个关键的命令参数，-i参数接受需要分析的文件（例如jar包），-a参数配置分析策略（例如是选择context sensitive还是context insensitive），--app-only参数配置开启doop的app only模式，--information-flow开启doop的信息流分析模式（可以用来做污点分析），--platform设置分析需要的jdk平台，--fact-gen-cores配置生成facts的并发性。

本文使用的doop命令参数：

-a context-insensitive --app-only --information-flow spring --fact-gen-cores 4 -i docs/commons-text.jar --platform java_8 --stats none

3.3 重新编译打包commons text

下载commons text的源码，自定义两条class和method注解TestctxTaintedClassAnnotation、TestctxTaintedParamAnnotation：

注解实现为一个空注解，主要是为了标注一下我们的source，将注解打到对应的class类和方法：

重新编译打包为jar包，得到2中命令参数-i的commons-text.jar。

3.4 改造doop app only下的规则

然而其中没有包含String split函数的污点转移规则，需要添加上：

为了确保方法的可达性，我们还添加了

ImplicitReachable("") :- isMethod("").但后续看不一定有必要，仅供参考。

通过注解我们在规则中定义了source，接下来需要定义sink，我们将Engine的eval方法定义为sink：

于是需要定义

OptTaintedtransMethodInvocationBase关系。

在此基础上，为了完成新的污点转移，doop需要根据以下自定义规则分析出返回值的类型信息。

基于以上的污点转移过程分析规则，应用到污点变量的转移分析规则中。

在结果集中的LeakingTaintedInformation.csv文件中可以找到我们需要捕捉到的souce-sink流。

LeakingTaintedInformation.csv给出了污点信息。包括污点的标签（这里是默认的default，可以自定义），sink方法的调用信息，该sink方法对应的污点源头souce信息。

如上图可以看出，

org.apache.commons.text.lookup.StringLookup:

java.lang.String lookup(java.lang.String)中调用到

javax..Engine.eval，并且污点的源头是

org.apache.commons.text.StringSubstitutor:

java.lang.String replace(java.lang.String)方法的参数@parameter0。

同时，在结果集中的AppTaintedVar.csv文件也可以看到具体的应用代码中由于污点传播过程中的被污染的变量.以上面commons text 漏洞执行方法栈中的

org.apache.commons.text.StringSubstitutor的resolveVariable为例：

可以看出方法中被污染的入参variableName、buf，还有resolver，以及$stack7等(这是经过soot生成jimple的过程中SSA pack部分优化新增的栈变量)。

基于这两个结果集基本可以看出漏洞的触发流程或者说污点的传播过程（虽然不是特别直观），如果需要也可以再搭配生成的CallGraphEdge.csv去更方便的进行分析。

四、总结

doop直接用来分析大型项目需要一定的计算资源，并且无论是规则的定制还是分析结果查看都不是特别直观，毕竟它的设计初衷就是一款分析框架，用在实际漏扫漏洞挖掘中可能需要进一步包装修改 。但可以看出，doop作为一款优秀的开源静态分析框架，在算法上毋庸置疑是比较先进和丰富的，而且基于开源的算法规则，我们可以任意去定制我们需要的分析逻辑。其与codeql在设计思路也较为相近，将程序信息提取后生成数据库，开放查询接口，将程序分析转变为数据关系的查询，因此可以扩展出更多的用途。

近期有较多投资机构在寻找优质开源创业项目，有意向可以添加微信 Hikalin，获取一手信息。

近期有较多投资机构在寻找优质开源创业项目，有意向可以添加微信 Hikalin，获取一手信息。

END

马斯克承认“家丑”，去年大裁员给自己挖了坑

这里有最新开源资讯、软件更新、技术干货等内容

点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦 返回搜狐，查看更多