关于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

那么就直接写一个

override predicate 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方法，这个方法需要满足正则表达式：

COMMAND_WHITE_LIST =  "[^\\w%,@/:=?.\"\\[\\]]";

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

自从用了数据流，挖洞都轻松了很多。
用CodeQL分析1day 很轻松 看看cve描述 然后挖掘一下就基本上可以把没poc的漏洞分析出利用方式了。
apache kylin就有一个新的cve 也是国人提交的，大家可以试试分析下