如何用CodeQL数据流复现 apache kylin命令执行漏洞

关于apache kylin漏洞就2篇帖子：

https://mp.weixin.qq.com/s/QzlHYST0kIqjNV-hnosyAw

https://www.freebuf.com/vuls/243541.html

其中，CVE-2020-1392是jd蓝军发现的。

直接就开始分析吧，首先分析sink，

Sink就很简单

这里的 sink我们就正常的去定义一个construtorCall，然后这个construtorCall限定在processBuilder下就行。如果你不会写，那就很棒棒了，codeql官方有一个ExternalProcess.qll库里面有一个ArgumentToExec类，这个类会覆盖到这个sink

那么就直接写一个

overridepredicate isSink(DataFlow::Node sink) {        sink.asExpr() instanceof ArgumentToExec}

就定义好了sink。

接下来定义source。

我们看到漏洞的分析里，漏洞最开始的参数是来源于

这的注解的project参数。这个project应该就是一个任务的名字。

对于这个source 的定义的话，就可以判断下他的注解和参数，参数也是有注解的，把这个抽象出来一个method

代码就是

class DumpProjectDiagnosisInfoMethod extends Method {
     DumpProjectDiagnosisInfoMethod() {
    //    this.hasName("dumpProjectDiagnosisInfo")
     this.getSourceDeclaration().getAnAnnotation().toString().matches("%Mapping%")  and
     this.getAParameter().getAnAnnotation().toString().matches("PathVariable")
    }
}

接下来我们可以看到整个漏洞的产生有不断的调用方法。

那么定义一个

class CallTaintStep extends  TaintTracking::AdditionalTaintStep {
    override  predicate step(DataFlow::Node n1, DataFlow::Node n2) {
      exists(Call  call |
        n1.asExpr()  = call.getAnArgument() and
        n2.asExpr()  = call
      )
    }
}

来保证调用关系。

然后我们跑下codeQL

可以看到source有3个地方可以流入processbuilder，分别是CubeController.java,DiagnosisController.java这2个文件，其中Diagnosisxx.java这个文件有2个注解方法可以流入到processbuilder。分别获得了CVE-2020-13925，CVE-2020-1956。

京东的那个分析文章也说了，漏洞存在的2个接口，而我们多了一个。这个会不会存在问题呢？

我们来看下他的数据流：

可以看到数据流第5步经过了一个checkParameterWhiteList方法，这个方法需要满足正则表达式：

反正我是绕不过。绕过了 这就是一个新的CVE了。但是放心，这个数据流是通的。

自从用了数据流，挖洞都轻松了很多。

本文始发于微信公众号（xsser的博客）：如何用CodeQL数据流复现 apache kylin命令执行漏洞