聊聊漏洞自动修复技术的行业现状

泉哥

发布于 2020-12-30 16:14:21

9270

发布于 2020-12-30 16:14:21

好久没写公众号了，收集整理了当前学术界与工业界的一些漏洞自动修复技术，对此作个简单分类与记录，谈谈原理，也聊聊个人看法。

1、基于依赖组件版本的修复方法

现在有很多包管理器，比如npm、maven，在里面指定下第三方组件版本号即可。所以如果想自动修复开源组件的历史漏洞，通过爬虫监控一些安全公告站点，去收集历史漏洞相关的版本信息，然后就可以直接生成安全版本号，然后Pull Request去合并即可。

去年Github收购Dependabot后，就是专门干了这件事。

这种自动修复方式目前我们也已经应用了，准确度理论上也可以做到100％。除了用在日常检测与修复漏洞外，用于安全应急也是个不错的选择。

漏洞信息的收集也是个长期积累的过程，还有那种包依赖另一包的死循环问题，也是项令人头疼的问题，目前可能没有特别好的解决方案。

2、基于程序移植的修复方式

2015年麻省理工学院发布了一款叫CodePhage的漏洞自动修复系统（研究论文：https://people.csail.mit.edu/stelios/papers/codephage_pldi15.pdf），它不需要程序源码，其输入样本是：一个可造成目标程序（Recipient，接收者）崩溃，一个不会，然后从程序代码仓库中去搜索能够同时满足两个样本情况的程序（Donor，贡献者）。将两个样本的执行路径进行对比以定位错误位置（Candidate Check Discovery），提取Donor对输入数据的处理逻辑，以生成对应的补丁代码（Check Excision），然后插入错误位置进行修复（Check Insertion），再收集上下文信息对补丁代码进行适配转换（Check Translation），最后再验证补丁是否消除（Patch Validation）。

下面是CodePhage的实际案例测试结果：

整个系统都是假设修复代码可以在其它程序中找到，这条其实很难满足的。几年过去了，这种修复方式的影响非常小，也证明了这一点。如果是同一帮人写的代码，那么就可能出现相似的漏洞，行业对这种寻找相似漏洞的分析方式，称为变体分析（Variant Analysis）。所以，这种检测方式倒不如用来挖掘相似漏洞，而不是寻找修复代码。

3、基于AST与模板的修复方式

今年陌陌发布一个IDEA插件用于检测Java代码漏洞并提供自动修复代码生成的功能。它利用IDEA的Inspection机制去检测代码，提供“一键修复”功能，这种方式对开发者非常友好。

检测原理也比较简单，就是利用IDEA SDK提供的接口从语法上去检测表达式，判断程序使用的是哪个XML解析类：

public void visitMethodCallExpression(PsiMethodCallExpression expression) {
  if (MoExpressionUtils.hasFullQualifiedName(expression, "javax.xml.parsers.DocumentBuilderFactory", "newInstance")) {
    commonExpressionCheck(expression, "setFeature", XmlFactory.DOCUMENT_BUILDER_FACTORY, false);
  } else if (MoExpressionUtils.hasFullQualifiedName(expression, "javax.xml.parsers.SAXParserFactory", "newInstance")) {
    commonExpressionCheck(expression, "setFeature", XmlFactory.SAX_PARSER_FACTORY, false);
  } else if (MoExpressionUtils.hasFullQualifiedName(expression, "javax.xml.transform.sax.SAXTransformerFactory", "newInstance")) {
    commonExpressionCheck(expression, "setAttribute", XmlFactory.SAX_TRANSFORMER_FACTORY, true);
  } else if (MoExpressionUtils.hasFullQualifiedName(expression, "org.xml.sax.helpers.XMLReaderFactory", "createXMLReader")) {
    commonExpressionCheck(expression, "setFeature", XmlFactory.XML_READER_FACTORY, false);
  } else if (MoExpressionUtils.hasFullQualifiedName(expression, "javax.xml.validation.SchemaFactory", "newInstance")) {
    commonExpressionCheck(expression, "setProperty", XmlFactory.SCHEMA_FACTORY, false);
  } else if (MoExpressionUtils.hasFullQualifiedName(expression, "javax.xml.stream.XMLInputFactory", "newFactory")) {
    commonExpressionCheck(expression, "setProperty", XmlFactory.XML_INPUT_FACTORY, false);
  } else if (MoExpressionUtils.hasFullQualifiedName(expression, "javax.xml.transform.TransformerFactory", "newInstance")) {
    commonExpressionCheck(expression, "setAttribute", XmlFactory.TRANSFORMER_FACTORY, true);
  } else if (MoExpressionUtils.hasFullQualifiedName(expression, "javax.xml.validation.Schema", "newValidator")) {
    commonExpressionCheck(expression, "setProperty", XmlFactory.VALIDATOR_OF_SCHEMA, false);
  }
}

然后根据不同的XML解析类的修复模板生成代码：

// 生成待插入的语句内容
List<String> blockTextes = new ArrayList<>();
if (xmlFactory.equals(XmlFactory.DOCUMENT_BUILDER_FACTORY) ||
    xmlFactory.equals(XmlFactory.SAX_PARSER_FACTORY) ||
    xmlFactory.equals(XmlFactory.SAX_BUILDER) ||
    xmlFactory.equals(XmlFactory.SAX_READER) ||
    xmlFactory.equals(XmlFactory.XML_READER_FACTORY)
) {
    blockTextes.add(varName + ".setFeature(\"http://apache.org/xml/features/disallow-doctype-decl\", true);");
} else if (
    xmlFactory.equals(XmlFactory.SAX_TRANSFORMER_FACTORY) ||
    xmlFactory.equals(XmlFactory.TRANSFORMER_FACTORY)
) {
    blockTextes.add(varName+".setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, \"\");");
    blockTextes.add(varName+".setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, \"\");");
} else if (
    xmlFactory.equals(XmlFactory.SCHEMA_FACTORY) ||
    xmlFactory.equals(XmlFactory.XML_INPUT_FACTORY) ||
    xmlFactory.equals(XmlFactory.VALIDATOR_OF_SCHEMA)
) {
    blockTextes.add(varName+".setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, \"\");");
    blockTextes.add(varName+".setProperty(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, \"\");");
}

这是开发过程中的检测与修复方式，还有开发完成后的检测与修复方式，在实际商业产品中，我只在RIPS中见过。

RIPS在检测代码发现漏洞后，会将source与sink存入数据库，然后对漏洞类型进行比较细化的分类，再根据分类寻找对应的修复代码模板，再将source这些上下文信息代入模块中生成最终的补丁代码。

修复代码模板如下：

这种结合AST与模板的生成方案，准确率还是比较高的，但是支持的范围相对比较有限，代码逻辑一复杂就无法修复，更多地还是针对简单漏洞模型的修复。

4、基于约束求解与符号执行的修复方式

这种方法更多是针对缓冲区溢出一类内存破坏漏洞的修复，对源码和二进制都适用。对于检测到漏洞，先通过分析CFG控制流图、符号执行分析，生成路径可达条件和漏洞触发条件取交后的约束，再进行约束求解，根据求解结果生成相应的修复代码。比如加入对缓冲区边界的条件判断、将不安全的函数替换成安全函数、增大缓冲区内存大小等等。

可参考研究论文“BovInspector: Automatic Inspection and Repair of Buffer Overflow Vulnerabilities”：

https://seg.nju.edu.cn/uploadPublication/copyright/116-553503409.pdf

这种针对特定漏洞类型还是比较适用的，比如溢出，但因为涉及路径分析、符号执行、约束求解，对性能是一种挑战，还有路径爆炸等问题，对于大程序分析是一大挑战，也并不是那么通用。

5、基于AI的修复方式