CSS大会 | 打破常“规”:挖掘语法解析器规则漏洞

2019年7月30-31日,第五届互联网安全领袖峰会(CSS 2019)在北京开幕。作为前沿技术安全研究团队代表,Tencent Blade Team两位高级安全研究员受邀登台,探讨如何挖掘语法解析器规则漏洞。

许多基础软件中都包含有语法解析部分,一旦出现规则漏洞影响,范围极大,而这块领域的安全研究相对较为缺乏,此次Tencent Blade Team对如何挖掘语法解析器规则漏洞做了从理论到实战的详细分析,并提出了如何编写安全的规则建议。

Tencent Blade Team由腾讯安全平台部成立,专注于物联网,AI,移动互联网,云技术,区块链等技术领域的前瞻性安全研究,积累了大量成果,包括发现首个谷歌TensorFlow AI框架漏洞、远程操控智能家居与商业楼宇、破解亚马逊智能音箱Echo、Google Home,发现SQLite Magellan漏洞等,多次受邀参加Blackhat、DEF CON、CSS等海内外顶级安全会议。

8月7号-11号,Tencent Blade Team也会前往美国拉斯维加斯参加BlachHat和DEFCON,一共有五场分享,涉及3个前沿议题:GoogleHome破解及麦哲伦漏洞利用,首次揭秘远程攻破高通Wi-Fi及Modem系统,远程利用高通硬件视频解码器漏洞,欢迎各位小伙伴关注。

以下为此次Tencent Blade Team挖掘语法解析器规则漏洞的现场分享,内容有删减,如有偏颇,敬请指正:

大家好,我们是来自Tencent Blade Team安全研究员,这是我们第二次来CSS分享议题,今天的分享主要分为以下六块内容:

  1. 研究背景、研究现状;
  2. 语法解析器概述,包括攻击面等;
  3. 如何人工挖掘语法规则的漏洞;
  4. 使用结构化fuzzer进行漏洞挖掘;
  5. 我们有关的研究成果;
  6. 如何编写安全的规则

首先,先来介绍我们研究语法解析器安全的背景:

一、研究背景及现状

不少基础软件的关键功能里,都能看到语法解析器的身影,例如SQLite,Chrome,PHP等,如果语法解析器存在安全问题,影响面很广,而语法解析器的安全问题,大家可能关注不多,容易被忽略。

二、语法解析器概述

接下来我们来了解一些关于语法解析器的基础知识。

右边的图是一个简单的编译流程图,在早期,编写编译器相当耗时,直到Lex和YACC的诞生,有了它们,开发者只需要关注如何设计词法和语法规则,剩下的解析器代码都由它们来生成处理,大大提高了程序编译解析器开发的效率。

我们的议题重点关注Lex&YACC和LEMON Parser Generator。

在Lex YACC解析器中,生成解析器的流程如右图所示。给定一段代码,由该解析器进行词法/语法解析,生成最终的结果。

介绍了有关语法解析器的基础知识,接下来分析其中的安全风险。

三、如何人工挖掘语法规则的漏洞

首先是Lex和YACC历史漏洞不多,但词法/语法规则是由开发者定义的,虽然Lex 和YACC的代码不多,漏洞较少,但规则就好比我们开发的插件,如果插件有问题,这个软件也存在安全风险。因此规则上引入的漏洞是我们关注的重点。

我们主要是对GLSL和SQL语法解析器进行了研究,目标确认了两个CVE和一些其他类型的多个crash。我们希望能够给大家提供一个新的攻击面和思路,以此抛砖引玉。

接下来,我们来看一下Lex和YACC的攻击模型。

正如右图所示,黄色部分表示可能被攻击的攻击面,分别对应四个处理程序(Lex,YACC,yylex,yyparse)。但在实际攻击场景,规则其实早已定义好,规则在程序中相当于常量。所以,只有对yylex和yyparse的输入代码才是真正的攻击面,这其中包括:编译器的生成代码以及开发者引入的规则代码。我们重点关注规则代码。

正如右上图的一个片段,解析器代码风格迥异,直接审计有些尴尬。由于我们更关心用户规则引入的代码,因此只需重点看switch分支的代码,或者直接分析. l和. y后缀的规则文件进行漏洞挖掘。

接下来,我们以一个漏洞代码为例,介绍根据规则找漏洞的方法。

首先,我们先看右上图,这是这个测试程序。该程序解析输入的print语法,把print后面的内容打印输出,否则提示语法错误。

再来看词法规则,词法规则是对输入文本的第一层过滤,处理完后会把内容传递给语法解析器(yyparse),这其中可能会存在以下问题:

1  错误的正则表达式,使得本该非法的字符传递给给了语法解析器; 2  错误使用输入的处理函数,可能会把类型转错传递给语法解析器。

接着,来看语法规则的漏洞模式:

正如右上图代码所示,print_console这个规则里,会把WORD(词素)传递到printf函数里($2表示为WORD),那么在第一步词法分析中,非法的输入hello%已经被当做WORD(词素),并且传递到了$2的位置。再加上语法规则代码里直接通过不规范的printf输出。那么两者结合起来,这就是一个标准的格式化漏洞,能够通过这个程序泄露出内存数据。

实际上,相比传统漏洞代码,语法规则从逻辑上看,malloc mencpy等内存操作的逻辑相对较少。所以可以尝试挖掘类型混淆漏洞。

下面部分,我们给大家介绍怎么用结构化模糊测试去挖掘语法规则漏洞。

四、使用结构化fuzzer进行漏洞挖掘

Fuzz是最常见的漏洞挖掘方式,目前常见的Fuzzer基本都是基于灰盒和白盒测试的。而这几年fuzzer也逐渐从傻瓜化变得智能化。但是最近又提出了一个概念,结构化。为什么要结构化呢?

哪些程序适合使用这种模糊测试方案呢?

第一个就是:这个程序应当是高度结构化的。如果是那种单纯处理数据,而不进行Parse(解析)的处理程序,就不太适用于结构化fuzz。另一个,是基于文本的,像C语言的代码、SQL语句,它们是以单词为单位的,这和传统的Fuzz以字节为单位有所不同,所以更适合用结构化Fuzz。我们接下来要讲的SQLite、SwiftShader、ANGLE之类的,都是符合这个条件的。

五、已有研究

谷歌的实现是基于libprotobuf-mutator 又叫LPM,或者LPMFuzzer。它进一步用protobuf的格式,作出了一组通用的框架,来衍生出对其使用组件的一系列的fuzz,比如对SQLite的fuzz。在Blade Team去年报告了SQLite漏洞以后,可以看到谷歌把SQLite的代码都加强了很多。

但为什么谷歌不把所有的Fuzz都改成结构化相关的呢?答案就在这里,SQLite的Fuzzer在谷歌的工程里,翻一下就可以看到。代码有2700行,非常大。这个写起来想必也是十分耗费精力。而如果被测工具有了新的语法,Fuzzer就得同步更新,也就是说,通过用C++代码定义语法,Fuzzer逐渐失去了它的灵活性,但是Fuzzer会变得非常专注。这个长期维护的人力,很有可能就是谷歌不愿意通篇全部替换的原因。

另一种,则是类似Csmith这种生成式Fuzzer,其他例子还有Mozilla的jsfunfuzz,以及我之前模仿写的一个lucky-js-fuzzer,它们都会基于一定规则生成符合目标程序的指令,从而减少因为无效指令带来的测试效率的损失。

而我们的方案,则是用简单的操作,把被测目标拆分,降低结构化fuzz的难度,同时,又融合生成式Fuzzer的语句的生成方案。最后,不重复造轮子,比如Sanitizer,比如突变算法,还用原来的。我们做出来了一个介于Csmith和谷歌之间的,简单的实现方案,我们会开源其中一个Fuzzer,后面会给出URL。

这个就是libfuzzer原本的突变方式,在没有什么特殊的指导的情况下,它可能会以比特为单位进行增删修改,这可能会产生大量无效用例。对SQL之类的,效率很低。

这是另一个版本,按照语素为单位,不过大家应该很快就能看出来,这和词典模式几乎没什么区别,只是我们做了一个形如虚拟机一样的东西,实现了一套我们自己的字节码定义,很像x86-CPU的那种变长字节码的感觉。这样,我们一来可以减少测试数据的长度,可以按照语素为单位来变换输出的内容。

相当于Fuzz引擎提供原始字节码,通过翻译,翻译出对应的语句,再去Fuzz,通过这种方式来跑,对比直接按字符为单位,空跑效率大概提升了40%多。当然,长时间以后收敛在一个比较接近的位置上。不过,这个情况下仍然能继续优化。

这一页展示的是用字节码定义整个语义的策略,可以看到,用语义为单位,会导致字节码变得十分长,但是也带来一个好处就是,Fuzz引擎的突变,更多的可能是改变语句内部的一些结构,但结果可能仍然是有效、完整的语句概率十分大。

而上一张我们说到的情况则仍然可能产生大量无效语句。不过用语义去Fuzz有什么问题呢?对,就是复杂度的问题。你可以看到SELECT FROM仅仅这一句,就有大量可能,如果让我们去开发程序,给每种不同的完整语句定义字节码,那几乎是一个不可能完成的任务。

所以我们在定义语义的时候,从关键字处,按语义将其拆分成最简化的句子,后续的内容采用类似生成式Fuzz的方案,尽量让它们能够在某个范围内成为一整条语句。这里语义的递归的逻辑就交给Fuzzer的突变引擎去随机弄就好了。

最终我们混合了上一页的策略、以及刚刚我们说的以语义为单位的Fuzz两种策略,做出了一套结构化Fuzz的东西。这套系统有个好处就是,你不需要费劲去搜集那么多初始样本,只要空跑或者随便给个什么文件当初始用例,就可以跑出来比普通的基于样本+词典更好的效果。

Tencent Blade Team去年在对Google Home进行研究的时候,顺便也对GPU进程做了个Fuzz,然后就发现SwiftShader可能是一个比较好的入口,我们当时做了很简单的一个结构化的模糊测试,很快我们就抓到了这样一个漏洞。

右边是生成它的具体Fuzzer代码。这样一个PoC有什么玄机呢,让我们继续往后看。

POC在第一张图中。那么为什么会导致这样的问题呢,让我们阅读一下layout相关的语法规则。GLSL的语法类似于C语言,也就是说,在一个数字后面加上u,这个数字就代表一个无符号数。

让我们先看第二个图,在文法规则中,我们看到,在只要版本号符合要求,layout即被定义为大写的LAYOUT。然后,在第三张图中,我们可以看到.Y中引用了大写的LAYOUT文法。再看第四张图,在glslang.y中,layout的规则定义为layout_qualifier,第1030行,即: LAYOUT 左括号 layout_qualifier_id_list 右括号。

不过这里要说明一下,因为它是从左往右一个token 一个token扫描的,所以我们最简PoC不写右括号也没事,因为在到右括号之前代码就出问题了。

这里大写的都是常量文本字符串,所以看第一个小写的,画红色横线的layout_qualifier_id_list,它的定义有两种,一种是直接layout_qualifier_id,一种是list 逗号 id。id的定义我用蓝色横线画出来了。

我们的显然是前一种,让我们再看看layout_qualifier_id的定义,它有三个定义,最底下那个不就是我们的这个情况嘛!表达式等于无符号数,直接调用parseLayoutQualifier,有符号数和无符号数的规则是一模一样的。大部分情况下,有符号数无符号数一样没什么大问题。

让我们看一下它生成出的 C文件,case 154对应无符号数规则。这里还需要介绍一下yyvsp和yylsp的概念。Yy就是yacc的那个y,大家可以读一下它的代码,他们写的时候并不是十分规范,大量使用了全局变量,我猜测这个yy是为了避免生成的代码。

和它自己的代码冲突而加上的一个模拟C++namespace的东西,如果觉得看着很碍眼,可以在阅读的时候把yy全部删掉。VSP,Value Stack Pointer,值栈指针;LSP,Location Stack Pointer,位置栈指针。它处理单词时,VSP永远指向正在处理的token。所以不难理解,现在它扫描到8686u,所以-1的位置就是等号,-2的位置就是location。

让我们看看最感兴趣的第三个参数,这也是他明显写错的地方。*Yyvsp[0],取出来的是数字,然后它将这个数字直接转为了String,这个.string的定义是Tstring对象,一个base_string,如果你传给它的是一个数字,它会把它当成const char*,也就是一个指针!

而第四个参数则直接取出数字传入下一层。

让我们对照代码看看出了什么问题。Tstring由0x86868686直接构造,也就是这个Tstring对象指向的是0x86868686这个地址,这里已经有一个错误了。

还有哪里有错误?我们可以看到,之前有符号数和无符号数共用了一个parseLayoutQualifier,而它的第四个参数是int ,有符号数。无符号数传入后,直接变成了有符号数。但为什么有符号数的情况下不会触发呢?

答案就在下面的if处,这里intValue因为是有符号数,而无符号数0x86868686的最高位是1,转换符号以后,变成了一个小于0的数,所以这个if被它自己这个强制符号转换给绕过去了。而下面立刻会调用error输出错误语句,这个错误语句中,直接调用了intValueString.c_str(),还记得intValueString现在是指向0x86868686的吗?所以在这里直接读取它的内容时,触发一次存取违例或者SIGSEGV。

右上角是我在VS里面调的,因为c_str()实际上会偏移几个字节,所以这里你看到的是868A或者868E等等,都正常,和平台相关。

另一个则是SQLite的问题,这个是去年发现的,去年我们发现了麦哲伦漏洞,其实它一共有5个漏洞,一半是靠Fuzz出来的,一半是靠人工看出来的。虽然在数据库系统上可以远程导致崩溃也是个严重问题,不过这个20505呢,严格意义上说它比另外4个弱很多。

SQLite使用了Lemon Parser,它和Yacc&Lex很像,但是又不互相兼容,不过在右边Call Stack中大家一样能看到中间有个yy_reduce,最后它还是用了yy_这个标准开头。

左边的是这个问题的最简化的代码,大家如果写过SQL的话,很快就能发现这里有个诡异的地方,就是PRIMARY KEY里面有两个一样的主键。但是明显SQLite在这个地方把它放行了,在下一行去查询的时候,崩在右边这个位置。

这个漏洞可以看到主键处理的规则是:RIMARY KEY 左括号 列表 是否有自增 右括号 ON CONFLICT 冲突时怎么做,然后,直接调用sqlite3AddPrimaryKey。这个函数逻辑是添加主键的时候,先检查要添加的列是否是表中已有的列;

如果是已存在的列,则将其设置为主键。但是这个过程中并没有判断主键是否重复;这样,里面就有两个主键,但是第二个主键添加的时候,因为列表里已经有一个同样的主键,于是它虽然成了主键,但是却指向一个空位置。

在执行搜索的时候,sqlite3ExprAffinity中试图取出第二个主键对应的项目,取出来的是空。就导致了这个CRASH。

SQLite官方的修复是在添加完表以后,把这种主键从数据库里清理出去。但我其实更觉得重复主键的时候就应该直接报错。

后续,我们也会把我们对GLSL的Fuzz工具开源:

GLSL Fuzzer (for Swiftshader / ANGLE , etc.)

https://github.com/tencentbladeteam/css_2019_tools/glsl_fuzzer.cpp

YACC规则转词典文件工具

https://github.com/tencentbladeteam/css_2019_tools/yacc_to_dict.cpp

大家可以把它用在Fuzz各个GLSL相关的地方,比如SwiftShader,ANGLE之类的地方。

六、如何编写安全的规则

最后,我们简单介绍一下如何编写安全的规则。

1.避免类型混用

规则定义中,可能存在大量的类型转换(显式的和隐式的),需要对每种情况都做好单元测试,以防漏掉某个规则产生混用。

2.避免过于宽泛的定义

避免一个规则对应多种类型的变量,C系列是强类型的语言,尤其是从Java移植过来的代码,更要检验是否存在某个规则过于宽泛。

3.检查边界值

规则定义中也存在类似边界情况的问题,比如某些值未被规则包括,或者某些特殊情况会产生异常问题,这些都要考虑在内。

4.检查不正确的值传递

在嵌套调用时,值可能会以不同类型的状态传递。另外,值有可能以智能指针之类的形式传递,在处理多层嵌套调用时,一定要仔细检查结果是否正确。

感谢大家的聆听,我们在8月7号-11号也会前往美国拉斯维加斯参加Blackhat和DEFCON,一共有五场分享,涉及3个前沿议题:GoogleHome破解及麦哲伦漏洞利用,首次揭秘远程攻破高通Wi-Fi及Modem系统,远程利用高通硬件视频解码器漏洞,也欢迎给大家关注blade的官网:blade.tencent.com,或者通过邮箱:blade@tencent.com和我们交流!

原文发布于微信公众号 - 腾讯技术工程(Tencent_TEG)

原文发表时间:2019-07-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券