并且compileAndExecuteMethod()在執(zhí)行之前對(duì)表達(dá)式執(zhí)行額外檢查：

private  Object compileAndExecuteMethod(String expression, Map context, OgnlTask task) throws OgnlException {  Object tree;  if (enableExpressionCache) {    tree = expressions.get(expression);    if (tree == null) {      tree = Ognl.parseExpression(expression);      checkSimpleMethod(tree, context); //額外檢查    }

這意味著我們實(shí)際上可以從接收點(diǎn)中移除compileAndExecuteMethod()。

在重新運(yùn)行查詢后，高亮的getMethod()作為接收點(diǎn)的調(diào)用的結(jié)果消失了。但是，仍然有一些結(jié)果突出顯示了DefaultActionInvocation.java中的代碼，這些代碼被認(rèn)為是已經(jīng)被修復(fù)的，例如對(duì)getActionName()的調(diào)用，并且這里的數(shù)據(jù)路徑并不是很明顯。

路徑探索和進(jìn)一步查詢細(xì)化

為了研究為什么這個(gè)結(jié)果被標(biāo)記，就需要看到DataFlow庫(kù)用來產(chǎn)生這個(gè)結(jié)果的每個(gè)流程步驟。QL允許編寫特殊的路徑問題查詢，這些查詢可生成可逐節(jié)點(diǎn)探索的可變長(zhǎng)度路徑，DataFlow庫(kù)允許編寫輸出此數(shù)據(jù)的查詢。

LGTM本身沒有路徑問題查詢的路徑探索UI，因此需要使用另一個(gè)Semmle應(yīng)用程序：QL for Eclipse。這是一個(gè)Eclipse插件，其中包含一個(gè)可視化工具，允許完成污點(diǎn)跟蹤中的各個(gè)步驟。用戶可以免費(fèi)下載并安裝此Eclipse插件。它不僅可以在LGTM.com上對(duì)開源項(xiàng)目進(jìn)行離線分析，還可以提供更強(qiáng)大的開發(fā)環(huán)境。下文的查詢可以在semmle-security-java目錄下的Semmle/SecurityQueries Git存儲(chǔ)庫(kù)中找到。你可以按照README.md文件中的說明在Eclipse插件中運(yùn)行它們。

首先，在initial.ql中運(yùn)行查詢。 在QL for Eclipse中，從DefaultActionInvocation.java中選擇結(jié)果后，你可以在Path Explorer窗口中看到從源到接收點(diǎn)的詳細(xì)路徑。

在上圖中，你可以看到，經(jīng)過幾個(gè)步驟后，調(diào)用getActionName()返回的值會(huì)流入對(duì)pkg.getActionConfigs()返回的對(duì)象的get()調(diào)用中的參數(shù)：

String chainedTo = actionName + nameSeparator + resultCode

actionName來自某個(gè)地方的`getActionName`

ActionConfig chainedToConfig = pkg.getActionConfigs().get(chainedTo)

//chainedTo包含`actionName`并最終出現(xiàn)在`get`方法中

單擊下一步，就到了ValueStackShadowMap::get()方法，如下所示：

public Object get(Object key) {  Object value = super.get(key);  //<--- key gets tainted?  if ((value == null) && key instanceof String) {    value = valueStack.findValue((String) key);  //<--- findValue ended up evaluating `key`  }  return value;}

事實(shí)證明，因?yàn)閜kg.getActionConfigs()返回一個(gè)Map，而ValueStackShadowMap實(shí)現(xiàn)了Map接口，所以理論上pkg.getActionConfigs()返回的值可能是ValueStackShadowMap的一個(gè)實(shí)例。因此，QL DataFlow庫(kù)顯示了從變量chainedTo到類ValueStackShadowMap中的get()實(shí)現(xiàn)的潛在流程。實(shí)際上，ValueStackShadowMap類屬于jasperreports插件，該類的實(shí)例僅在幾個(gè)地方創(chuàng)建，并都不會(huì)被pkg.getActionConfigs()返回。在發(fā)現(xiàn)ValueStackShadowMap::get()不太可能被命中之后，作者通過在DataFlow::Configuration中添加一個(gè)過濾來刪除依賴它的結(jié)果：

override predicate isBarrier(DataFlow::Node node) {  exists(Method m | (m.hasName("get") or m.hasName("containsKey")) and    m.getDeclaringType().hasName("ValueStackShadowMap") and    node.getEnclosingCallable() = m  )}

這個(gè)predicate意思是如果非法數(shù)據(jù)流入ValueStackShadowMap的get()或containsKey()方法，那么就不要繼續(xù)跟蹤它。

新漏洞：CVE-2018-11776

只有10對(duì)源和接收點(diǎn)，就很容易通過手工檢查發(fā)現(xiàn)這些是否真正存在問題。通過一些路徑，作者發(fā)現(xiàn)有些路徑是無效的，因?yàn)樗鼈冊(cè)跍y(cè)試用例中，所以在查詢中添加了一些過濾來過濾掉這些路徑。這就留下了一些非常有趣的結(jié)果。

以ServletActionRedirectResult.java中的源代碼為例：

在第一步中，調(diào)用getNamespace（）的源通過變量namespace流入ActionMapping構(gòu)造函數(shù)的參數(shù)：

public void execute(ActionInvocation invocation) throws Exception {  actionName = conditionalParse(actionName, invocation);  if (namespace == null) {    namespace = invocation.getProxy().getNamespace();  //源  } else {    namespace = conditionalParse(namespace, invocation);  }  if (method == null) {    method = "";  } else {    method = conditionalParse(method, invocation);  }  String tmpLocation = actionMapper.getUriFromActionMapping(new ActionMapping(actionName, namespace, method, null)); //namespace進(jìn)入ActionMapping的構(gòu)造函數(shù)  setLocation(tmpLocation);

繼續(xù)執(zhí)行這些步驟之后，可以看到getUriFromActionMapping()返回一個(gè)URL字符串，該字符串使用構(gòu)造的ActionMapping中的namespace。然后通過變量tmpLocation流入setLocation()的參數(shù)，然后setLocation()在超類StrutsResultSupport中設(shè)置字段位置：

public void setLocation(String location) {    this.location = location;}

然后代碼在ServletActionResult上調(diào)用execute()：

String tmpLocation = actionMapper.getUriFromActionMapping(new ActionMapping(actionName, namespace, method, null));setLocation(tmpLocation);super.execute(invocation);

它將location字段傳遞給對(duì)conditionalParse()的調(diào)用：

public void execute(ActionInvocation invocation) throws Exception {    lastFinalLocation = conditionalParse(location, invocation);    doExecute(lastFinalLocation, invocation);}

然后conditionalParse()將位置傳遞給translateVariables():

protected String conditionalParse(String param, ActionInvocation invocation) {    if (parse && param != null && invocation != null) {        return TextParseUtil.translateVariables(            param,            invocation.getStack(),            new EncodingParsedValueEvaluator());    } else {        return param;    }}

所以當(dāng)在ServletActionRedirectResult中沒有設(shè)置namespace參數(shù)時(shí)，代碼從ActionProxy獲取namespace，然后將其作為OGNL表達(dá)式進(jìn)行評(píng)估。為了測(cè)試這個(gè)，作者通過以下方法替換了showcase應(yīng)用程序中的一個(gè)配置文件（例如struts-actionchaining.xml）中的struts標(biāo)記：

                                    register2                       

然后在本地運(yùn)行showcase應(yīng)用程序，并訪問了一個(gè)可以觸發(fā)此漏洞的URL并執(zhí)行shell命令以在計(jì)算機(jī)上打開計(jì)算器應(yīng)用程序。

不僅如此，來自ActionChainResult，PostbackResult和ServletUrlRenderer的不可信來源也同樣有效！PortletActionRedirectResult中的那個(gè)可能也可以，但沒有被測(cè)試。四個(gè)RCE足以證明問題的嚴(yán)重性。

看完上述內(nèi)容，你們掌握如何通過Semmle QL找到Apache Struts的遠(yuǎn)程執(zhí)行代碼.的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！