一、doop靜態(tài)分析框架簡介

1. doop靜態(tài)分析框架簡介

doop靜態(tài)分析框架由希臘雅典大學(xué)plast-lab Yannis Smaragdakis團(tuán)隊設(shè)計開發(fā)，目前看是一款開源領(lǐng)域的比較先進(jìn)的程序靜態(tài)分析框架，一些程序靜態(tài)分析論文的理論也有通過doop的規(guī)則實現(xiàn)后實驗。

doop整體架構(gòu)簡單明了，符合通常靜態(tài)代碼漏洞掃描工具掃描器內(nèi)核的設(shè)計思路。架構(gòu)上由groovy寫的調(diào)用程序“粘合”在一起，通過調(diào)用fact-generator和datalog分析器，得出自動化的分析結(jié)果。

下面是筆者畫的doop整體架構(gòu)圖，包含doop中一些關(guān)鍵的組件模塊：

2. doop工作流程

doop的fact generator模塊會對輸入進(jìn)行解析（例如jar包的解析或者類的resolve從而加載進(jìn)必要的類信息到內(nèi)存中）

調(diào)用soot、wala等工具生成jimple IR，在此基礎(chǔ)上生成后續(xù)分析引擎需要的facts文件。而后doop使用LogicBlox（目前doop已不維護(hù)）或者Soufflé（開源的datalog分析引擎）

基于facts文件和既定的datalog分析規(guī)則文件進(jìn)行分析，得到最終的程序分析結(jié)果。

doop支持對java源碼及字節(jié)碼的分析，不過源碼的jdk版本受限，建議直接使用字節(jié)碼進(jìn)行分析。

doop核心是其實現(xiàn)的一套datalog分析規(guī)則，其中包含了由粗糙到精細(xì)的context-insensitive、1-call-site-sensitive、1-call-site-sensitive+heap的豐富的靜態(tài)程序分析策略等等等，同時通過在addons中添加了額外的對信息流分析、對spring等生態(tài)框架、對java反射特性的支持，十分強大。

以上是對doop的架構(gòu)和功能的簡單介紹，jar包信息的解析、規(guī)則的預(yù)處理、編譯執(zhí)行和解釋執(zhí)行、程序的并發(fā)設(shè)計或者由于大量sootclass加載造成的內(nèi)存溢出問題等一些細(xì)節(jié)由于篇幅限制不在此介紹。

二、commons text rce漏洞簡介

先對該漏洞進(jìn)行簡單介紹。

Apache Commons Text是一款處理字符串和文本塊的開源項目，之前被披露存在CVE-2022-42889遠(yuǎn)程代碼執(zhí)行漏洞，這個漏洞目前網(wǎng)上的分析文章比較多，在此不做復(fù)述。該漏洞原理上有點類似log4j2，當(dāng)然影響不可相比，其代碼中存在可以造成代碼執(zhí)行的插值器，例如ScriptStringLookup（當(dāng)然這里提到這個插值器是因為我們目標(biāo)就是分析這一條sink污點流），同時沒有對輸入字符串的安全性進(jìn)行驗證導(dǎo)致問題。

借用網(wǎng)上公開的poc觸發(fā)ScriptStringLookup中的代碼執(zhí)行，使用commons text 1.9版本 ：

完整的漏洞調(diào)用棧如下：

從調(diào)用棧可以看出，通過調(diào)用commons text的字符串替換函數(shù)，可以調(diào)用到ScriptStringLookup類的lookup方法，從而調(diào)用scriptEngine.eval執(zhí)行代碼。可以看出該條漏洞鏈路較淺，但鏈路關(guān)鍵節(jié)點也涉及了接口抽象類的cast、輸入字符串的詞法分析狀態(tài)機以及各種字符串的處理函數(shù)，作為實驗對象非常合適。

三、commons text rce污點信息流的doop識別規(guī)則

我們選取上述二中commons text中

org.apache.commons.text.StringSubstitutor replace函數(shù)作為source，ScriptEngine eval函數(shù)作為sink。

doop設(shè)置app only模式去進(jìn)行分析，doop在app only模式下會將!ApplicationMethod(?signature)加入isOpaqueMethod(?signature)，這樣一些分析不會進(jìn)入jdk的類中，可以大大提高doop的分析效率。依據(jù)萊斯定理，靜態(tài)程序分析難以達(dá)到完全的完備(truth或者perfect)，也是盡可能優(yōu)化sound。類似在企業(yè)級的SAST部署使用也是如此，也需要在掃描精度、掃描速度以及實際可用性中進(jìn)行取舍或者平衡，所以doop的app only模式下在個人看來更接近實際嵌入到devsecops中的輕量級靜態(tài)代碼漏洞掃描的應(yīng)用。

3.1 doop的datalog分析規(guī)則簡單介紹

由于涉及doop app only規(guī)則的改造，首先先簡單介紹doop使用的datalog規(guī)則。

doop目前維護(hù)使用開源的Soufflé分析datalog規(guī)則。datalog是聲明式的編程語言，也是prolog語言的非圖靈完備子集，所以本質(zhì)上也是建立在形式邏輯中的一階邏輯上。所以基礎(chǔ)概念也是命題推導(dǎo)，在Soufflé的形式上就是表現(xiàn)為關(guān)系（relation）。

如下例子：

很明顯可以看出該例子通過datalog定義的關(guān)系邏輯實現(xiàn)相等關(guān)系的自反性、對稱性和傳遞性，首先定義了equivalence關(guān)系，該關(guān)系可以由rel1和rel2關(guān)系蘊涵得到，而equivalence的a需要滿足關(guān)系rel1，b需要滿足關(guān)系rel2。具體語法和高階特性可以通過souffle-lang.github.io網(wǎng)站進(jìn)行了解。

3.2 doop配置使用簡單介紹

doop可以通過gradle去編譯使用，需要提前在類unix系統(tǒng)中借助cmake編譯安裝Soufflé，doop的具體安裝使用可以在https://github.com/plast-lab/doop-mirror中了解。

對doop的命令行使用進(jìn)行簡單，分析，有幾個關(guān)鍵的命令參數(shù)，-i參數(shù)接受需要分析的文件（例如jar包），-a參數(shù)配置分析策略（例如是選擇context sensitive還是context insensitive），--app-only參數(shù)配置開啟doop的app only模式，--information-flow開啟doop的信息流分析模式（可以用來做污點分析），--platform設(shè)置分析需要的jdk平臺，--fact-gen-cores配置生成facts的并發(fā)性。

本文使用的doop命令參數(shù)：

-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

這是我最初使用doop分析commos text的方法，主要為了盡可能減輕的對原生規(guī)則的侵入。doop在使用jackee進(jìn)行分析事，分析入口的確定及一些mockobject的構(gòu)建都需要依賴于對springmvc注解的識別。

下載commons text的源碼，自定義兩條class和method注解TestctxTaintedClassAnnotation、TestctxTaintedParamAnnotation：

注解實現(xiàn)為一個空注解，主要是為了標(biāo)注一下我們的source，將注解打到對應(yīng)的class類和方法：

重新編譯打包為jar包，得到2中命令參數(shù)-i的commons-text.jar。

3.4 改造doop app only下的規(guī)則

doop的污點信息流識別依賴于指針分析結(jié)果，同時也依賴污點轉(zhuǎn)移函數(shù)。doop中已經(jīng)預(yù)置了多條污點轉(zhuǎn)移函數(shù)，其中包含了字符串、鏈表、迭代器等基礎(chǔ)類方法。

ParamToBaseTaintTransferMethod(0, "").
ParamToBaseTaintTransferMethod(0, "").
ParamToBaseTaintTransferMethod(0, "").
ParamToBaseTaintTransferMethod(0, "").
ParamToBaseTaintTransferMethod(0, "").
ParamToBaseTaintTransferMethod(0, "").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").
BaseToRetTaintTransferMethod("").

然而其中沒有包含String split函數(shù)的污點轉(zhuǎn)移規(guī)則，需要添加上：

BaseToRetTaintTransferMethod("").

如上述，doop自有的jackee規(guī)則肯定沒有包含我們自定義的注解，所以需要在EntryPointClass、Mockobj等關(guān)系定義中添加對我們自定義的class污點注解的識別。

EntryPointClass(?type) :-
   //...
   Type_Annotation(?type, "org.apache.commons.text.TestctxTaintedClassAnnotation");
 
//...
MockObject(?mockObj, ?type) :-
  //...
   Type_Annotation(?type, "org.apache.commons.text.TestctxTaintedClassAnnotation");

同時也需要添加param污點的注解。doop需要通過這些注解識別分析入口方法，構(gòu)建污點mockobj，建立初始的指向關(guān)系等。

//...
mainAnalysis.VarPointsTo(?hctx, cat(cat(cat(cat(?to, "::: "), ?type), "::: "), "ASSIGN"), ?ctx, ?to) :-
  FormalParam(?idx, ?meth, ?to),
  (Param_Annotation(?meth, ?idx, "org.springframework.web.bind.annotation.RequestParam");
  Param_Annotation(?meth, ?idx, "org.springframework.web.bind.annotation.RequestBody");
  Param_Annotation(?meth, ?idx, "org.apache.commons.text.TestctxTaintedParamAnnotation");

為了確保方法的可達(dá)性，我們還添加了

ImplicitReachable("") :- isMethod("").但后續(xù)看不一定有必要，僅供參考。

通過注解我們在規(guī)則中定義了source，接下來需要定義sink，我們將ScriptEngine的eval方法定義為sink：

LeakingSinkMethodArg("default",0,method):-isMethod(method),match("",method).

正如前述，由于是在app only下，doop下通過OpaqueMethod關(guān)系過濾了jdk類的識別，這樣會導(dǎo)致相應(yīng)的上述預(yù)置的污點轉(zhuǎn)移函數(shù)無法完成污點轉(zhuǎn)移，所以需要另外定制規(guī)則流去將轉(zhuǎn)移函數(shù)包含進(jìn)數(shù)據(jù)流分析過程。

于是需要定義

OptTaintedtransMethodInvocationBase關(guān)系。

.decl OptTaintedtransMethodInvocationBase(?invocation:MethodInvocation,?method:Method,?ctx:configuration.Context,?base:Var)
OptTaintedtransMethodInvocationBase(?invocation,?tomethod,?ctx,?base) :-
  ReachableContext(?ctx, ?inmethod),
//Reachable(?inmethod),
  Instruction_Method(?invocation, ?inmethod),
  (
  _VirtualMethodInvocation(?invocation, _, ?tomethod, ?base, _);
  _SpecialMethodInvocation(?invocation, _, ?tomethod, ?base, _)
  ).

在此基礎(chǔ)上，為了完成新的污點轉(zhuǎn)移，doop需要根據(jù)以下自定義規(guī)則分析出返回值的類型信息。

.decl MaytaintedInvocationInfo(?invocation:MethodInvocation,?type:Type,?ret:Var)
MaytaintedInvocationInfo(?invocation, ?type, ?ret) :-
  Method_ReturnType(?method, ?type),
  MethodInvocation_Method(?invocation, ?method),
  AssignReturnValue(?invocation, ?ret).
 
.decl MaytaintedTypeForReturnValue(?type:Type, ?ret:Var, ?invocation:MethodInvocation)
MaytaintedTypeForReturnValue(?type, ?ret, ?invocation) :-
  MaytaintedInvocationInfo(?invocation, ?type, ?ret),
  !VarIsCast(?ret).

基于以上的污點轉(zhuǎn)移過程分析規(guī)則，應(yīng)用到污點變量的轉(zhuǎn)移分析規(guī)則中。

VarIsTaintedFromVar(?type, ?ctx, ?ret, ?ctx, ?base) :-
  //mainAnalysis.OptTaintedtransMethodInvocationBase(?invocation,?method,?base),
  mainAnalysis.OptTaintedtransMethodInvocationBase(?invocation,?method,?ctx,?base),
  MaytaintedTypeForReturnValue(?type, ?ret, ?invocation),
  BaseToRetTaintTransferMethod(?method).
  //mainAnalysis.VarPointsTo(_, _, ?ctx, ?base).

同時也需要重新定義LeakingSinkVariable關(guān)系，因為我們這里自定義的sink方法也是Opaque方法，這樣才能識別到我們的ScriptEngine 的eval方法。

LeakingSinkVariable(?label, ?invocation, ?ctx, ?var) :-
  LeakingSinkMethodArg(?label, ?index, ?tomethod),
  mainAnalysis.OptTaintedtransMethodInvocationBase(?invocation,?tomethod,?ctx,?base),
  //mainAnalysis.VarPointsTo(_, _, ?ctx, ?base),//here problem
  ActualParam(?index, ?invocation, ?var).

從上面規(guī)則的定義可以看出，改造的流程還是比較清晰的，并且通過關(guān)系的名字，這些關(guān)系的含義和用途也很容易理解。添加這些自定義規(guī)則到我們的doop分析中運行，在結(jié)果中可以看出，doop完成了對commons text的污點信息流的識別。

在結(jié)果集中的LeakingTaintedInformation.csv文件中可以找到我們需要捕捉到的souce-sink流。

defaultdefault<>/javax.script.ScriptEngine.eval/0/@parameter0

LeakingTaintedInformation.csv給出了污點信息。包括污點的標(biāo)簽（這里是默認(rèn)的default，可以自定義），sink方法的調(diào)用信息，該sink方法對應(yīng)的污點源頭souce信息。

如上圖可以看出，

org.apache.commons.text.lookup.ScriptStringLookup:

java.lang.String lookup(java.lang.String)中調(diào)用到

javax.script.ScriptEngine.eval，并且污點的源頭是

org.apache.commons.text.StringSubstitutor:

java.lang.String replace(java.lang.String)方法的參數(shù)@parameter0。

同時，在結(jié)果集中的AppTaintedVar.csv文件也可以看到具體的應(yīng)用代碼中由于污點傳播過程中的被污染的變量.以上面commons text 漏洞執(zhí)行方法棧中的

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

可以看出方法中被污染的入?yún)ariableName、buf，還有resolver，以及$stack7等(這是經(jīng)過soot生成jimple的過程中SSA pack部分優(yōu)化新增的棧變量)。

基于這兩個結(jié)果集基本可以看出漏洞的觸發(fā)流程或者說污點的傳播過程（雖然不是特別直觀），如果需要也可以再搭配生成的CallGraphEdge.csv去更方便的進(jìn)行分析。

四、總結(jié)

doop直接用來分析大型項目需要一定的計算資源，并且無論是規(guī)則的定制還是分析結(jié)果查看都不是特別直觀，畢竟它的設(shè)計初衷就是一款分析框架，用在實際漏掃漏洞挖掘中可能需要進(jìn)一步包裝修改 。但可以看出，doop作為一款優(yōu)秀的開源靜態(tài)分析框架，在算法上毋庸置疑是比較先進(jìn)和豐富的，而且基于開源的算法規(guī)則，我們可以任意去定制我們需要的分析邏輯。其與codeql在設(shè)計思路也較為相近，將程序信息提取后生成數(shù)據(jù)庫，開放查詢接口，將程序分析轉(zhuǎn)變?yōu)閿?shù)據(jù)關(guān)系的查詢，因此可以擴(kuò)展出更多的用途。

審核編輯：劉清