Codeql 原理分析（一）

Codeql原理概述

codeql整个漏洞扫描可以分为两部分：

AST数据库创建，通过命令行工具即可
规则编写，类似SQL的语法来编写漏洞查询规则

分为编译型语言和非编译型语言

非编译型语言，如python、js

1
codeql database create --language=javascript --source-root <folder-to-extract> databaseName

编译型语言，如cpp、go

1
codeql database create "xxx" --language=cpp -c "gcc main.c"

编译出来的数据库长这样：

1
.
2
├── baseline-info.json
3
├── codeql-database.yml
4
├── db-javascript
5
│   ├── default
6
│   ├── semmlecode.javascript.dbscheme
7
│   └── semmlecode.javascript.dbscheme.stats
8
├── diagnostic
9
│   ├── cli-diagnostics-add-20231128T030607.340Z.json
10
│   ├── extractors
11
│   └── tracer
12
├── log
13
│   └── database-create-20231128.110453.457.log
14
└── src.zip

重点是 db-javascript 文件夹，包含了对应的AST结构数据库结构
log 目录和日志相关
src.zip是源代码的备份

规则编写——打点

一个简单的规则

比如任意文件读取漏洞，如下 fs.readFile 函数存在任意文件读取漏洞

1
const express = require('express');
2
const fs = require('fs');
3
const app = express();
4

5
app.get('/getFile', (req, res) => {
6
  const fileName = req.query.fileName;
7
  fs.readFile(fileName, 'utf8', (err, data) => {
8
    if (err) {
9
      res.status(500).send(err.toString());
10
    } else {
11
      res.send(data);
12
    }
13
  });
14
});
15

16
app.listen(3000);

我们可以将代码中含有 fs.readFile 函数的代码都提取出来，编写规则如下：

1
/**
2
 * @name fs-read-file
3
 * @kind problem
4
 * @problem.severity warning
5
 * @tags correctness
6
 * @id js
7
 */
8

9
import javascript
10

11
from CallExpr fsReadFile
12
where
13
  fsReadFile.getCalleeName() = "readFile"
14
select fsReadFile, "This is a call to fs.readFile."

codeql查询本质是通过AST树来查找的，写法类似SQL的写法

from 定义变量，比如我们想查询 readFile ，这是一个函数调用表达式 CallExpr
还有一些限制条件，这个函数调用表达式的被调用函数名称，类似 sql 的where条件写法
最后select出查询的结果

当然很明显，存在大量的误报，所有的 fs.readFile 函数都会被认为是存在漏洞

所以我们面临一个问题，即如何区分正常的代码和有污点的代码 sink

污点分析原理

如图，我们定义

source：数据源，代表直接引入不受信任的数据或者机密数据到系统中
sink：污点汇聚点，代表直接产生安全敏感操作或者泄露隐私数据到外界

至于其中经过的一个个Node，可以认为是词法分析里最小的一个个Token，代表着if、while、for、函数调用等

污点分析的步骤：

只要我们标记了source和sink， codeql会判断只要满足有一条路径能够从 source 流向 sink ，就会认为这是一个漏洞

污点分析的局限

官方没有公开原理，但是经过多轮测试我们发现codeql追踪最准的还是赋值语句，路径更多的是形式上的，并且没有考虑到语言特性：

代码1：

1
let x = process.argv[0]
2
let ctrl = 1
3
let y
4

5
if(ctrl > 0){
6
    y = 1
7
}else{
8
    y = x
9
}
10
eval(y)

source 定义为 process.argv[0]
sink 定义为 eval(y)

尽管 ctrl 永远是大于0的，但codeql还是会判断存在从source到sink的路径

代码2

1
let x = process.argv[0]
2
Object.prototype.a = x
3

4
let y = {}
5
eval(y.a)
6

7
// 或者
8
let x = process.argv[0]
9

10
let c = {}
11
c.a = x
12

13
let y = {
14
    b:c
15
}
16
eval(y.b.a)

实际上这里都存在问题，但codeql均无法召回

细化污点规则

codeql的判断是比较有限的，如果仅仅标记source和sink会出现大量的误报和漏报情况

分析这些情况，大致可以归纳从 source 到 sink 所经过的代码路径为如下四种（代码特性的除外需要额外做判断）

经过一系列正常的 if、while 等正常流程到达 sink
经过一个filter函数过滤到达sink
经过一个check函数，如果不满足条件，则无法到达sink，但形式上还是可以流向sink的
经过一个正常的join等函数到达sink

数据源通过无害处理到达污点sink

1
const express = require('express');
2
const fs = require('fs');
3
const app = express();
4

5
function sanitizePath(path) {
6
  // 简单的清理逻辑，例如移除路径导航字符
7
  return path.replace(/(\.\.\/|\/\.\.)/g, '');
8
}
9

10

11
app.get('/getFile', (req, res) => {
12
  const fileName = req.query.fileName;
13
  const safeFileName = sanitizePath(fileName);
14
  fs.readFile(safeFileName, 'utf8', (err, data) => {
15
    if (err) {
16
      res.status(500).send(err.toString());
17
    } else {
18
      res.send(data);
19
    }
20
  });
21
});
22

23
app.listen(3000);

数据源检查不通过直接返回

1
const express = require('express');
2
const fs = require('fs');
3
const app = express();
4

5

6
const SAFE_DIRECTORY = '/path/to/safe/directory';
7

8
app.get('/getFile', (req, res) => {
9
  const fileName = req.query.fileName;
10
  if (!fileName.startsWith(SAFE_DIRECTORY)) {
11
    // 不允许读取
12
    return res.status(403).send('Access denied');
13
  }
14
  fs.readFile(fileName, 'utf8', (err, data) => {
15
    if (err) {
16
      res.status(500).send(err.toString());
17
    } else {
18
      res.send(data);
19
    }
20
  });
21
});
22

23
app.listen(3000);

数据源直接到达污点，或者经过多个处理到达污点（实际是两种）

1
const express = require('express');
2
const fs = require('fs');
3
const path = require('path');
4
const app = express();
5

6
app.get('/getLog', (req, res) => {
7
  const logFile = req.query.logFile;
8
  const logPath = path.join(__dirname, 'logs', logFile); // 经过path.join
9
  fs.readFile(logPath, 'utf8', (err, data) => {
10
    if (err) {
11
      res.status(500).send(err.toString());
12
    } else {
13
      res.send(data);
14
    }
15
  });
16
});
17

18
app.listen(3000);

因此我们需要做额外的处理，除了定义source和sink之外，还需要增加 barrier、sanitizer、AdditionTaintStep

filter：无害处理(sanitizer)，代表通过数据加密或者移除危害操作等手段使数据传播不再对软件系统的信息安全产生危害
barrier：屏障，不同于sanitizer，barrier不清理或改变数据，而是作为条件检查或决策点，阻止数据流的某些路径。
AdditionTaintStep: source在传递的过程中可能断开，这时需要手动连接

编写污点分析规则

codeql中提供了两种方式来分析

静态规则，即AST树查询，以AST树节点的方式呈现，属于静态分析
动态规则，即数据流DataFlow查询，抽象为 DataFlow::Node 基类，属于动态分析

AST树很好理解，DataFlow 会有点抽象，主要分为几种不同的节点

DataFlow::Node 可以表示程序里的任何元素，基类，即词法分析里的Token

1
var x = 10; // 'x' 和 '10' 都可以是 DataFlow::Node 的实例
2
var y = x + 5; // 'y', 'x + 5', 'x', 和 '5' 也都是 DataFlow::Node 的实例

DataFlow::ValueNode 用于表示程序中的值或者表达式

1
var name = "Alice"; // 'name' 和 "Alice" 都是 DataFlow::ValueNode 的实例
2
function greet() {
3
    return "Hello, " + name; // 'return "Hello, " + name;' 是 DataFlow::ValueNode 的实例
4
}

DataFlow::SourceNode 表示程序的输入点，如用户输入，文件读取等
DataFlow::SinkNode 表示可能存在sink的点
DataFlow::PathNode 用于敏感数据分析的变量，没有特殊的用途了

编写规则一般的流程是：

定义source，即输入数据源是什么，可以理解为是外部输入的数据
定义sink，即污点代码，比如 readFile
定义isBarrier、isSanitizer、isAdditionalTaintStep （非必需，只是为了减少误报和漏报）

一般框架如下：

1
import javascript
2
import DataFlow::PathGraph
3
import Express
4

5
class FileReadFromUserInput extends TaintTracking::Configuration {
6
  FileReadFromUserInput() { this = "FileReadFromUserInput" }
7

8
  override predicate isSource(DataFlow::Node source) {
9
    // 定义Source
10
  }
11
  override predicate isSink(DataFlow::Node sink) {
12
    // 定义Sink
13
  }
14
}

codeql通过类似函数的写法，结合AST语法树的查询来打点标记，比如标记eval处的sink点

1
   override predicate isSink(DataFlow::Node sink) {
2
    // Eval is a sink
3
    exists(CallExpr call |
4
        call.getCalleeName() = "eval" and
5
        sink.asExpr() = call.getArgument(0)
6
      )
7
   }

最后查询：

1
from FileReadFromUserInput cfg, DataFlow::PathNode source, DataFlow::PathNode sink
2
where cfg.hasFlowPath(source, sink)
3
select sink.getNode(), source, sink, "$@ flows to $@ ", source.getNode(), source.toString(), sink.getNode(), sink.toString()

Source

express框架里，Source一般比较固定，即 req.query.xxxx 就是外部输入的数据

Source的编写本质也是通过AST语法树来查找，对于现成的框架如express，codeql有编写好的规则可以直接用

1
override predicate isSource(DataFlow::Node source) {
2
    exists(Express::RouteHandler rh, DataFlow::SourceNode sn |
3
        sn = rh.getARequestSource() and
4
        source = sn.getAPropertyRead("query").getAPropertyRead()
5
    )
6
}

exists 也是一个谓词，这里是为了简单地引入临时变量
Express::RouteHandler 是内置的一个规则，能查找出express对应的路由处理代码

注意这里的 = 要从右到左看，本质上是赋值的意思

写完之后就可以马上select一下看看结果：

Sink

由于是处理任意文件读取漏洞，sink就是我们最开始编写的查找 readFile 调用。额外注意的是，还需要标注对应的sink点

fs.readFile 的第一个参数是可能被控制的点，因此通过

sink.asExpr() = call.getArgument(0) (这里的sink要做下数据类型转换，DataFlow和AST节点是两个模型）

1
  override predicate isSink(DataFlow::Node sink) {
2
    exists(CallExpr call |
3
        call.getCalleeName() = "readFile" and
4
        sink.asExpr() = call.getArgument(0)
5
      )
6
  }

AdditionalTaintStep

但是这种情况下会存在漏洞，比如这个就无法找到，因为经过了 path.join ，source被传递了

1
const express = require('express');
2
const fs = require('fs');
3
const path = require('path');
4
const app = express();
5

6
app.get('/getLog', (req, res) => {
7
  const logFile = req.query.logFile;
8
  const logPath = path.join(__dirname, 'logs', logFile);
9
  fs.readFile(logPath, 'utf8', (err, data) => {
10
    if (err) {
11
      res.status(500).send(err.toString());
12
    } else {
13
      res.send(data);
14
    }
15
  });
16
});
17

18
app.listen(3000);

所以需要额外编写一个 isAdditionalTaintStep，即如果遇到了 join 这种函数，可以视作source经过了一次传递，后继节点可以继续连接上

1
  override predicate isAdditionalTaintStep(DataFlow::Node pred, DataFlow::Node succ) {
2
    exists(CallExpr call |
3
        call.getCalleeName() = "join" and (
4
            pred.asExpr() = call.getAnArgument() and succ.asExpr() = call
5
        )
6
    )
7
  }

最终汇总的规则与结果分析

最后的规则汇总，不过还是存在一些误报，即没有处理 sanitizer

1
/**
2
 * @name file-read-from-user-input
3
 * @kind path-problem
4
 * @problem.severity warning
5
 * @tags correctness
6
 * @id js
7
 */
8

9
import javascript
10
import DataFlow::PathGraph
11
import Express
12

13
class FileReadFromUserInput extends TaintTracking::Configuration {
14
  FileReadFromUserInput() { this = "FileReadFromUserInput" }
15

16
  override predicate isSource(DataFlow::Node source) {
17
      exists(Express::RouteHandler rh, DataFlow::SourceNode sn |
18
          sn = rh.getARequestSource() and
19
          source = sn.getAPropertyRead("query").getAPropertyRead()
20
      )
21
  }
22
  override predicate isSink(DataFlow::Node sink) {
23
    exists(CallExpr call |
24
        call.getCalleeName() = "readFile" and
25
        sink.asExpr() = call.getArgument(0)
26
      )
27
  }
28

29
  override predicate isAdditionalTaintStep(DataFlow::Node pred, DataFlow::Node succ) {
30
    exists(CallExpr call |
31
        call.getCalleeName() = "join" and (
32
            pred.asExpr() = call.getAnArgument() and succ.asExpr() = call
33
        )
34
    )
35
  }
36

37
}
38

39
from FileReadFromUserInput cfg, DataFlow::PathNode source, DataFlow::PathNode sink
40
where cfg.hasFlowPath(source, sink)
41
select sink.getNode(), source, sink, "$@ flows to $@ ", source.getNode(), source.toString(), sink.getNode(), sink.toString()

Select的结果中也可以看到数据流向