G.O.S.S.I.P 阅读推荐 2022-09-29 ODGen

今天给大家推荐的论文是来自今年刚刚从约研究组毕业的，现已加入浙大网安豪华套餐团队的李松老师投稿的关于Node.JS程序的安全性的研究工作Mining Node.js Vulnerabilities via Object Dependence Graph and Query，该工作已经发表在今年的USENIX Security上啦~

Node.JS是一个服务器端的JavaScript运行平台。NPM(Node.js软件包管理工具)为Node.js平台提供了数以万计的第三方包。在这些包中，有着大量的包存在着安全漏洞。这些漏洞可能会严重危害Node.JS程序的安全性。

过去发明了许多侦测程序漏洞的方法。一种方法是基于程序设计侦测Node.js漏洞的方法，能够对Node.js的漏洞进行查询，但只能针对个别类型的漏洞进行分析。另一种方法是基于C/C++和PHP的研究已经提出基于图查询的方法，能够对多种漏洞进行查询，很高效，但不能直接对拥有大量动态特性的JavaScript使用。

在本文中，作者针对于JavaScript多漏洞检测难的问题，提出了一种新的图查询方法。作者提出了一种名为对象依赖图（Object Dependence Graph）表达方式，来表示一个javaScript程序。JavaScript程序用对象依赖图表示后，一些漏洞会通过图的某些特征表现出来。通过在该图上查询对应JavaScript漏洞的图特征可以侦测出对应漏洞。与此同时，作者实现了一个流敏感、上下文敏感的抽象解释器（ODGen）用以生成该图。实验结果表明，对象依赖图及其相关图查询可以检测13种不同的漏洞类型，并且在NPM库中检测到180个零日漏洞，其中包括43个可以直接用于攻击的应用级漏洞和137个库漏洞。截至论文发表时，ODGen检测到的零日漏洞已被授予70个CVE标识符。

Motivating Example

图1 Motivating Example

JavaScript作为有着大量动态特性的语言，其静态分析结果难以准确，比如静态分析难以准确分析出对象间的继承关系。举个例子，在图1中所示的代码片段中，“source1” 和 “source2”是两个攻击者可以控制的变量。这可能会引发两种不同的漏洞。

内部属性篡改：这个漏洞发生在第5行，当source2是“__proto__”时被激发。此时myFunc的原型不再是Func.prototype，而被修改为myFunc.x+source1。在第5行和第6行读取myFunc.x值的过程是不同的。
1）在第5行访问myFunc的属性x时，会先查找对象myFunc是否存在属性x，发现不存在后，会接着查找对象myFunc的原型Func.prototype是否存在一个属性x，发现存在后，返回Func.prototype.x（“ab”）做为myFunc.x的值。
2）在第6行访问myFunc的属性x时，会先查找对象myFunc是否存在属性x，发现不存在后，会接着查找myFunc的原型是否存在一个属性x，但myFunc的原型已经被修改成“ab”+source1,而不再是 Func.prototype，从而无法正确访问myFunc.x
命令注入：这个漏洞发生在第6行,当source2是“x”时被激发。这段代码将直接用一个对手可控制的变量source1去产生对象myFunc的新属性x。接下来，当代码在第6行读取myFunc.x时，会先查找对象myFunc是否存在属性x，发现存在后，返回“ab”+source1作为myFunc.x的值。Sink函数接受myFunc.x的值作为参数，执行相应功能。若攻击者将“ab”+source1设置为系统命令对应的字符串，并且sink函数的功能是执行参数myFunc.x对应的系统命令。将会使系统执行攻击者想执行的命令，从而引发命令注入漏洞。

上述两个漏洞的检测关键在于准确分析第5行中myFunc[source2]的值，以及myFunc和第2行中 Func.prototype的继承关系。正是由于传统的静态分析难以准确表达出myFunc和Func的继承关系，从而难以准确寻找myFunc.x的内容，最终无法准确检测上述两种漏洞。

下面针对图一所示的两种漏洞，讲解如何用对象依赖图来侦测上述两种漏洞

1. 首先，生成图1所示的JavaScript程序对应的对象依赖图

如图2所示，图2上半部分是由该JavaScript程序的抽象语法树(AST)、控制流图（CFG）和程序依赖图（PDG）整合成的代码属性图(CPG)，图2下半部分是该JavaScript程序的部分对象依赖图。

如图中所示，蓝色的结点是对象依赖图(ODG)为每个对象变量（相当于引用)创建的名字节点。蓝色结点里包括其所代表的对象的变量名。空白的小圆圈代表一个具体的对象，一个对象可以有多个对象变量指向它。

在边的方面，橙色边称为Property edge。它可以从名字节点指向对象节点，或者从对象节点指向名字节点---如果是前者，则表示该对象节点是名字节点所指代的对象；如果是后者，则表示该名字节点指向的对象是该对象节点的属性。

黑色虚线边AST-Obj lookup是对象依赖图中连接AST中的对象变量结点(AST的叶节点)到对应的具体对象的边。我们可以利用这种边查询某个AST节点的解析结果所对应的对象节点。

紫色虚线边Object def.是对象依赖图中从一个具体对象指向程序中创建该对象的AST节点。

棕色虚线边Data flow从一个对象节点指向另外一个对象节点，表示后一个对象节点的数据依赖于前一个对象节点。

图2: ODG示意图

2. 然后，在图中查找各漏洞对应的一些特征，来判定漏洞是否存在

作者通过利用内部属性篡改(Internal Property Tampering)的漏洞侦测过程和命令注入（command injection）的漏洞侦测过程，实现了一个开源的原型ODGen，包含三个主要部分：对象依赖图的表示和查询组件，JavaScript 解析器，抽象解释器。然后，为评估ODGen在实际应用中建模Node.js包漏洞的能力，作者用ODGen查询synk.io数据库提供的在NPM上Node.js包的最新漏洞。之后，作者人工浏览下载的原始漏洞包，并分析在CVE和snyk.io上的描述来判断漏洞的类别。接下来，按照CPG论文中采用的评估方法，手动分析在Node.js中描述这些漏洞类别所需的代码表示。下表展示了ODG在JavaScript程序漏洞侦测能力的分析结果：ODGen能建模16种漏洞中的13种。

表1：不同图表达支持的漏洞检查类型

为了评估ODGen侦测应用等级和包等级的Node.js的零日漏洞，作者按照包周下载量降序获取了前300,000个NPM包并应用ODGen的图查询侦测相应漏洞。表2是ODGen侦测到的零日漏洞情况。其中应用级包（Application-level）的漏洞指攻击者仅需控制网络请求和返回即可发起有效攻击；非直接包漏洞（Indirect Package-level）指该库自身并没有漏洞，但是由于该库引用了有漏洞的库导致该包自身出现了漏洞；直接包漏洞（Direct Package-level）指该包自身即包含漏洞。

表2：ODGen检出的0day漏洞

False Positive Rate和False Negative Rate

由表2内容可知，在ODGen报出的264个潜在漏洞中，通过人工核查，其中180个漏洞为真实零日漏洞。其误报率（False Positive Rate）仅在32%（84/264)，如表3所示，和其他已有静态分析工具JsJoern的75%和JSTap-vul的80%相比有着巨大的提升。

表3：False Positive Rate对比

为衡量ODGen在漏检出率（False Negative Rate）上的表现，论文作者使用了传统已知漏洞CVE的数据库。在256个已知CVE中，ODGen成功检测到189个漏洞，检出率为73.8%。如表4所示，ODGen的表现远优于其他已有工具。

表4：False Negative Rate对比

运行效率

为衡量.的运行效率，作者随机选取了500个NPM包用以进行漏洞挖掘效率实验。结果如图5所示，在ODGen的分支敏感模式下，85%的NPM包可以在30秒内完成分析；在分支不敏感模式下，超过90%的包可以在30秒内完成分析。该结果证明ODGen对于NPM包的分析效率足够高。

图5：ODGen分析效率

论文下载：https://songli.io/papers/odgen.pdf

code：https://github.com/Song-Li/ODGen

投稿作者介绍：