当前位置: 首页 > 安全资讯 > 正文

张超:漏洞挖掘的艺术

摘要:模糊测试是近年来最流行的漏洞挖掘方法。研究人员也提出了众多的改进方案,极大提高了自动化漏洞挖掘的效率。本文中将介绍模糊测试面临的挑战,当前最前沿的研究进展,以及演讲人团队提出的解决方案。

张超

张超    清华大学副教授

今天的题目是“漏洞挖掘”。我本科和博士是在北大毕业,博士后毕业在伯克利工作三年,2016年底回到清华,我研究的方向是软件系统安全的方向,做了很多攻防相关事情,包括CGC做了自动化攻防,参加过微软的防御竞赛blueHat获得了特别评委奖,随着这个方案演化之后,变成了刚才宋凯讲到的CFG那个防范和实验部署,还有Defcon也参加过,当时蓝莲花的成员,获得2016年第二名的成绩。

我们蓝莲花队首先是清华的学生发起的,2013年第一次打入Defcon CGC半决赛,这是大陆第一次。2016年拿到第二名,是目前国内排到最优成绩的。右边列了过去五年Defcon的名次,第一名绝大部分都是PPP,是美国CNU大学带队;2015年第一名是韩国战队,因为当年出了一个很神奇的小伙子,很厉害,大家可以去了解一下。

CGC是我们做的最有意思的系统,也是目前正在研究推进的事情,做的是自动化攻防,刚才大家听到凯讲到,真的要找到漏洞,利用漏洞这么一长串的事情,非常复杂。即使你很有经验,做这个事情也要花很长的时间,这个比赛是三天的时间,题目相对要简单很多,一般大家花半天或一天的时间才能解出一道题,非常困难。真实的软件难度更大。CGC是美国国防部DARPA发起的一个项目,两年的时间花了5000万美元做这个事情,最终设计自动化攻防系统,有点像AlphaGo一样,它的任务不是下围棋,而是做黑客的事情,攻击防御的事情。当时我带领队伍参加这个比赛,资格赛的时候我们是行域(音)第一名,决赛时是防攻击一等奖(音)。我的研究是与CDC主题非常相关的。

今天我们的主题是漏洞挖掘,一个简单的故事是WannaCry,大家都知道。

WannaCry背后是因为美国NASA的合作承包商被攻击了,它的网络军火库被偷出来了,其中包括攻击武器,WannaCry就把这个攻击武器做了包装,写了一个勒索软件。这个泄漏的网络军火库里有攻击工具,这个攻击工具是因为有漏洞,大家知道SMB的漏洞,攻击工具可以利用这个漏洞发起攻击。微软在真正WannaCry爆发之前,3月份已经发布补丁,WannaCry是5月份爆发的,如果大家打过微软的补丁,WannaCry就没有事。

从科普角度看一下漏洞的模式,为什么漏洞很重要。从系统角度来看,用户的数据或计算机理比较重要的是数据,还有比较重要的事情是计算机上的控制权,在上面有运行代码,可以用在系统里。大家可以想想,攻击者在外面怎么攻击你的系统。我认为主要是两个攻击链,一是软件,你这个系统怎么着都得需要软件与外界进行交互;二是人,这两方面都很容易被突破,软件方面可能存在漏洞,人这边可能存在社交工程,比如钓鱼网站、欺诈,它以心理学相关的东西,欺骗人去下载一个恶意程序来安装的方式。通过这两种渠道之后,它最后进入到你的系统,一般形式是运行恶意代码,大家推说过病毒、蠕虫这些东西。我们这次通过软件漏洞进入系统方式,关注的是软件漏洞。软件漏洞,具体我们关注很常见一类的内存漏洞,包括缓冲区,除了Use-after-free等等漏洞,刚才宋凯也介绍了一个漏洞就是这个类型。这些漏洞是大家听过很多安全故事的根源。像苹果iOS越狱,Android的root,甚至包括伊朗核设施、震网病毒、心脏滴血Heart dripping等等,背后其实都是有着漏洞的。这些网络漏洞危害那么大,攻击当然也想挖洞,必须有漏洞能力攻击。防御方也是在考虑怎么挖漏洞,把漏洞挖出来,我可以把漏洞修掉,让攻击者没办法冲击。

怎么去挖漏洞?主要方式是两大类,第一是带上手机,人看源码或逆向工程,很多黑客很擅长做这个事儿,逆向做安全程序或审这个源代码,前段时间,360报的EOS的虚拟机漏洞,其实是人工审计中发现的。自动化方面,学术界提出了很多方法,包括程序分析里的静态分析和动态分析,污点分析,符号执行,我想重点说的最主要的是Fuzzing测试技术。当然,非公开数据说有80%以上可能都是用Fuzz技术来发现的,我重点介绍一下Fuzz怎么做漏洞挖掘。

Fuzz的基本想法很简单,就是给程序做测试,给程序进行大量输入,让程序运行,运行过程中程序出现了问题,比如程序崩溃了,那就是有漏洞。更聪明一点,在运行过程中监控这个程序,把监控的结果反馈给前面,前面再负责新的输入,这是基本的流程,非常简单的流程,和程序测试很像。这样的逻辑它都能实现,但我们简单实现一个东西效果很差,最关键的是我们怎么样有效生成这个输入,很快找到输入的触发漏洞,如果完全没有办法,随机的话,就比买彩票还难,因为输入空间太大了。所以,研究热点的时候我们怎么生成这个输入。

主要分类有两种,第一种是基于生成的,它的想法是,我们知道这个输入会长什么样,知道它的格式,知道它的word文档,是个word格式,我们生成的时候基于这个格式生成就好了。它要求我们比较知道输入的格式和规范,这不是所有情况下都有,有的并不知道它的输入长成这样。第二种是更通用的基于变异的,我们不需要教它语法,你给我的输入,我在输入上随便变异一下,像自然界中的变异,输入新的再测试就好了。基于生成有很多工作可以做,PEACH这是个开元的工具,它可以自己来定义,你告诉它输入什么样的格式,它会有文件指定这个格式。工具自动基于这个格式帮你做输入生成。除了数据格式之外,PEACH还提供程序内部处理输入,可以想象是很难的,要给程序做状态建模,相当于把程序写一遍,本身就是很复杂的事情。这个东西还是挺有效的,但工程量非常大,我也得告诉它输入规范,数据的规范和程序内部的状态,可能有不少工业界的人在用这个东西。基于变异,给我一个数据,随便从原来的输入这儿随便找一些自己进行编译,就得到新的样本。这是变异的第三个特点,三个样本。

这两个方案的对比,基于变异这种,它很容易设置,不需要知道这个输入应该采用什么格式,它的缺陷是,因为它不知道格式,格式进而是错的,错误的格式输入扔进去之后,程序给他拒绝了,导致代码测试的时候测试覆盖率比较低。还会遇到特殊的像校验格检查,MagicNubmer检查等等,如果你这个不对,程序也不帮他走,他测试的时候,后面代码测不到,会有这样的情况。反过来,基于生成类的话,它的特点是相反的。

在实践中,有很多种方案,除了这两种分类,还分黑盒、白盒、灰盒的,所谓白盒一般是指源码的;黑盒是什么都没有,只是搭个黑盒来测;介于两者之间的灰盒,意思是你可以在这个程序执行过程中获取一定程序的信息,灰盒应该说现在很常见,大家用的很多,我们重点介绍这一类。

实践中,如果人工去做Grammar based,要输入文档,可以做这个事情。通常我们没有这种,一般会采用基于编译的方法更好,它的扩展性更好。但它的局限在于coverage,它的覆盖率比较低,因为它没有格式信息,所以导致覆盖率比较低。为什么大家会关心覆盖率呢?漏洞,代码如果没覆盖的话,一定存在漏洞,肯定没法触发。在一定程度上,如果覆盖率不够的话,找到漏洞就更少,大家尽量提高自己的覆盖率,不同Fuzz都会尝试做覆盖率的提升。

怎么做覆盖率提升呢?有一类方法是基于覆盖率导向的Fuzz,代码是AFL。AFL是个开源的工具,是Google开发人员提供的。他的想法还比较聪明,类似跟杂交水稻一样进化的想法,杂交水稻目标是要找好的水稻种子,有比较高的产量。现在怎么做呢?他们会不断地培育新的种子,一轮一轮地培育,有好有坏,会把好的种子留下来,好的种子再进行下一轮种子杂交,会生成下一批种子,再选出好的种子进行杂交,这样的方式不断迭代,进化的想法,一代会比一代好,最终挑选出比较好的种子。在这里,AFL用了类似的想法,他找了一些种子触发漏洞或提高代码覆盖率,这是它的目标。它的做法也是一样的,其实中间的大循环也是一轮一轮的测试,它会把好的种子留下来,进入下一轮测试,会把这个好的种子进行编译,然后再测试,把好的留下来,这样一轮轮下来,最后达到比较好的效果。

什么是它的好种子?定义的标准是,如果这个种子对覆盖率的贡献,早期的代码别人没走过的代码,你的种子就是好的,就留下来了。就这么一个想法,让这个东西不断走下去,自然而然地最终达到测试的效果,它的覆盖率会比较好。AFL这个方案是基于编译的,可扩展性比较好,不需要太多的先验知识,它的测试速度非常快,基本和原始程序执行没有太多差别,原来程序能测多快它就能测多快。而且它可以支持并行化测试。另外一个特点,它比较敏感,与其他工具结合起来,可以捕获很多类型的漏洞,而不是简单地依赖Crash崩溃,有些漏洞触发时并不会崩溃,如果不会捕获这种漏洞你会漏掉这个漏洞。这几个特点导致AFL效果非常好,大家用的非常多,学术界也对它进行了很多扩展。

对它感兴趣的,首先会想我怎么选它初始种子?初始种子挺重要的,因为初始种子选得好,Fuzz测试会非常快,能达到比较好的出事状态,底下会走出很多代码。而且初始种子可以在不同的被测试程序之间进行共享,测一个PDF软件有一批种子,这批种子可以在下一个PDF软件里重用,效果非常好。怎么去找这种初始种子呢?我们程序里会自带benchmark,benchmark通常用于测功能的,它会有大量训练代码会辅到,所以,benchmark是比较好的输入live。没有benchmark的时候,我们会从网络上爬的样本里筛选,学术界里也有一些研究,2017年南洋理工的李奥(音)他们做的一篇文章,去年微软做的用RNN学习的想法,这两个工作核心的想法,是从大量已知样本里学出一种模式,比较符合有效输入格式,基于这个模式再生产新的种子。

对AFL第二块感兴趣的在于它的选种,刚才这个循环里,它每轮迭代其实是说,它会把上一轮留下来好的种子选一部分出来再进行变异杂交操作。怎么操作?上一轮留下来的可能不是一个种子,而是一百个种子,这一百个种子到底先选谁出来变异,这块学问研究非常多。先选为什么重要?如果选得好的话,展开100个种子,如果第一轮选第一个,第二轮选第二个,第一百轮选第一百个。选得特别好的话,第一轮你就把这个漏洞给触发,选得不好的话,等到第100个人才会触发这个漏洞,差别非常大。所以,选种子顺序是非常关键的。学术界在这块做了很多研究,包括2016年的CCS,这里列的都是顶级会议地,就是安全圈或者软件圈里的顶级漏洞。2016年CCS漏洞的想法是,怎么选这个漏洞,他会考虑这个种子被选出来过多少次,因为每个人会选出一个种子,他会评估100个种子哪个种子被选出多少次,有的种子选择了1万次,有的只选择了1次,这时候他会优先选被选的少的种子,背后的原理是,要给每个种子均等的机会,你选出来1万次的那个种子已经被充分测试过了,没有什么剩余价值了。

AFLgo 2017年CCS方案,这是一个比较特殊的方案,它不是针对覆盖率的,是针对另外一个时间,是定向化的。我们程序员写代码每次会提交commit,我们可能关心提到的这个commit里会不会有问题,他会说我用Fuzz测试新提出来的代码,按目标定向测试对象,他的目标是像原来Fuzz一样最终是要探索指定的代码行的东西。他的想法是,也是改种子选择策略,选种子的时候会考虑,这个种子离目标有多远,近的话如何选择,这样可以迭代,比较快地找到这些输入,触发目标的路径。

选完种子之后下一步进行变异,到测试地来测试。怎么编译,给你一个输入,你对这些输入进行改动,改动成什么内容?现在研究也包括Vuzzer的,Vuzzer这个工作是NDSS发表的,它其实核心解决两个问题,对什么地方进行编译,以及用什么值,他用数据模分析,分析这个程序输入怎么影响这个程序的运行。对哪些字节变异,他会考虑输入如果影响到某一个判断语句,输入的这几个字节就是他需要变异的地方。变异采用什么值呢?就是magic number,因为你经常会检查,IF某些字节等于magic number,这个magic number就是它要变异的值。最近,学者有提出来QEI(音)、RNN、GAN强化学习的方法来辅助指导Fuzz怎么进行编译,大家感兴趣可以去查这个paper。编译完之后要进行测试,核心问题是怎么让它测得更快。CCS有个工作室是做并行化测试,AFL本身是有并行化模式,但它的并行化模式效率比较低,达不到线性速率,CPU数量加上去之后没有效果,所以,CCS把这个并行化基本让它做线性,很好地提高了。在测试过程中,还有很关键的问题,怎么跟踪测试中出现的安全漏洞。

这里经典的工具是AddressSanitizer,这是很经典的工具,是Google提供的,能捕获缓冲区溢出和Use-after-free运行漏洞,非常经典。学术界在去年阿迪森(音译)的时候提出对AddressSanitizer感兴趣的工作AMAZ(音),除了捕获安全问题,还有更多代码覆盖率的问题,代码覆盖率是它的属性,要用覆盖率指导Fuzz,根据这个覆盖率跟踪判断这个种子是好的还是不好的,应不应该留下来。刚才已经简单回复了绝大多数基于Coverage based Fuzz学术界改进,获得更好效率的方案。这些方案考虑得很全面了了,还有可以改进的地方。我们注意到,他们说的是Coverage Guider Fuzz,这些方案里很少有几个方案真的很关心Coverage。

我们做了一个工作,就是Fuzz的CollAFL。

我们有两个观察,测试过程中,它会跟踪Coverage,它会和Coverage有碰撞。这不是我们第一次关注到,AFL作者知道碰撞,也写到自己文档里,但他选了折中的办法放在那儿。碰撞是怎么回事呢?要简单说一下细节,AFL要用到一个64KB bitmap来保存Coverage的信息。怎么保存的呢?他关心的是边的Coverage,这个程序的边到底怎么走过,边是有两个块连接构成,它怎么保存呢?它对每个基本块附了一个key,上面是prev,下面是cur,然后他算这个边,他给这个边算了哈希出来,这个哈希就代表这条边,更新bitmap的技术细节。这样的做法,原理很简单。大家看这个哈希算法很简单,会进行碰撞。两个不同的边算出来的哈希是一样的,碰撞有什么问题呢?最大的问题,它而影响这个Fuzzer的判断,这个Fuzzer会根据bitmap来判断当前这个种子是不是号种子,判断这个种子是不是走了新的边,如果碰撞了,它是看不出来这是新的边。如果新的边出现了,它的哈希值与前哈希值是一样的,那么Fuzzer认为这个边是测过的边,认为这个种子没用,其实扔掉了,但它实际是好的种子。

第二,它甚至可能帮你找到漏洞里了,因为找到漏洞,崩溃了,Fuzzor和AFL会做一个检测,会检查这是不是重复的崩溃,这个种子走的是和原来一模一样的东西,不是一模一样就认为是重复的,要扔掉了。同样的,碰撞以后导致这样的情况,就可以导致你漏掉漏洞。还有比较严重的是,bitmap碰撞以后导致它提供Coverage信息不准确,其他依赖Coverage信息做决策的,就会做出错误的决策,这就包括前面讲的怎么选种的问题,有策略,选种子的时候是基于Coverage做的判断,Coverage不准的话会导致他做出错误的判断。

这个问题是非常严重的,比大家想象的严重。我们做的测量,测了二十多个开元软件,他们碰撞像Libtorrent是75%的边会碰撞,整体效果影响会非常大的;nm边数小于64kb,碰撞率是36%;vim边数是大于64kb,碰撞更严重,超过60%(61.04%)。这个碰撞的问题不仅仅是AFL中存在,AFL会有更多边的概念,这算做得比较好的,其实有的Fuzz只是做基本块的覆盖率。大家注意,边的覆盖率会推导出基本块覆盖率,但基本块覆盖率推导不出来边的覆盖率。基本块的覆盖,很多工具是这么做的,像lib Fuzzer,cloud里带着这个,honggfuzz是Google后来提供的一个开源的Fuzz,他们都用的基本块覆盖率,里面的碰撞问题更严重。其实边覆盖率还不够,最好的情况应该考虑做路径覆盖率。因为边的顺序对漏洞还有影响,最理想的情况下是做漏洞覆盖率,但在代码中,工具没法实现的时候,我们做路径做到两条不同路径,它的内部表示还不一样,这个事情太大了,这个路径太长了,这个怎么存储?这中间太多了,每一次记录runtime的开销特别大,没有好的办法做这个事情,微软选择Edge也是非常好的选择,也许将来还会有提升。

关于Coverage第二个环节,现在这些策略里对Coverage没有考虑太多,其中一个是选种子,选种子也是基于它的测试速度,是不是离目标最近的策略选种子,但所有提到的策略里没有一个是直接和Coverage相关的,也没有哪个策略说我优选对Coverage有贡献的策略。Coverage会有碰撞,Coverage并没有被很好地应用Seed selection里去。

基于这两个观测,我们提出了新的方案——CollAFL方案,我们做了两嗯个改进,一是消除Coverage跟踪碰撞问题,二是选种的时候把Coverage作为优先策略来应用。

具体做法。

1、消除碰撞。

AFL用到64kb bitmap跟踪边的覆盖率。它的跟踪方式大概是这样的哈希算法。怎么消除碰撞呢?一个很简单的方式,把64kb bitmap增大,把哈希表变大一些,碰撞概率自然就会降低,这是很显然的事情,我们也试了一下,把bitmap大小变大,碰撞率自动降低了。但把bitmap加大之后,AFL测试速度也跟着马上往下降。所以,这不是个最优方案。

我们提出一个方案,不降低它的测试速度。怎么做呢?是按照替换哈希算法,哈希算法原来很简单,就是current key,当前基本块的key与上一个基本块的key做个异或的操作的,这里很简单,他用了1的常量,我们把它做了泛化,把当前的key做了x bit,前一个基本块key做了一个y,另外再加一个z,这样分三个参数泛化,原来是固定的。这样变成每条边就是x、y、z,变成我们寻找一个答案,每条边路来复制一个x、y、z来消除碰撞。我们碰到一个边搜一个x、y、z,让以前的哈希值不碰撞就行了。我不断地沿着这条边搜索下去,前面是一条边,显而易见搜索到后面的时候,前面已经搜索的,到了后面就非常难以找到合适的x、y、z与以前的哈希值不碰撞,非常难找,刚开始没有碰撞,到后来边就很难找。

怎么解决这个问题呢?我们不用对所有边那么不用算,有些直接赋个哈希值或者固定值就可以了。怎么做呢?有两种情形,第一种情形,这个基本块只有一个前驱,它直接就复制,这样就直接给条边附一个常数,不要运行时算这个哈希值,只要这个常数和别的哈希值不碰撞就完了,他就随便选,只要是没有人用这个哈希值就可以。第二种情形,还是我原来的策略,我搜索x、y、z,我怎么都搜索不出来x、y、z,怎么办呢?做法就是要用时间换空间的想法,我们直接给这条边也赋一个哈希值,这个哈希值存到哈希表里了,我们运行的时候就搜索哈希表。比如这边有条边,有个基本块,有两个前驱,我们搜不出来合适的x、y、z怎么办?我们就给这两个边静态赋一个哈希值,但这个哈希值不能将静态写死,只能通过runtime去查。我们把哈希值放到哈希表里,它的key就是前一个基本块的key和底下key两个组合起来做到key。之所以不能写死,因为有很多个禁区(音188:35),没法写死。对这两个问号都不用进行计算,要么直接静态赋行,要么运行查一下哈希表。总的来说,这三种模式,第一种是我们通常情况下去边搜索x、y、z,第二种是我实在搜不动了,它有多全驱,但我搜不到了,找不到x、y、z了,这时候就用哈希表,把它事先在静态中把它放到哈希表里,Hash demo里,runtime的时候去查这个哈希表就可以了;第三是single-precedent单驱,我直接给它赋个常数,这个常量我没用过就好。这个顺序必须严格按照这个顺序来,我们要解决碰撞问题。

实验室数据,这是基本把碰撞率消除为零,我们会对某些bitmap大小还是会扩大一些,因为边的数bitmap size超过64K,如果不把这个bitmap加大到64k怎么消除,这样的情况下,我们会把bitmap顺其自然地扩大,不是任意扩大。这三类当前区域最简单,给它赋予静态的哈希值,不需要运算,原来A表示对所有变量进行运算,现在要对当前变量进行运算。这个比例非常高,单前驱的基本块比例非常高,在程序中大部分的基本块都是单前驱的,这是好事儿,对这一情况都不用做运行式计算,它的碰撞和operate没有。最麻烦的是查哈希表的内容,我们严格控制哈希表的大小,如果哈希表大的话,runtime查询哈希表会非常慢,测试的时候会受到严重的影响。这里哈希表最多126个,查起来还是非常快,不受什么影响。它的速度比AFL快一些,相当于优化了,比原来的算法快一点,并且可以消除碰撞。

2、改进种子选择策略。

优先选择对Coverage有贡献的种子。我们提出几个策略,第一个策略,考虑每个种子会走一条路径,一条路径实际有不同分支的,有些分支是被其他种子测过,有的分支没有。我们会统计这个种子多样分支被测过,有多少分支没有被测过,可能有两个种子。第一个种子有一个分支没测过,第二个种子有100个分支没测过,我们选择第二个,因为在第二个进行变异的时候要有非常大的概率,种子有没有被触发、测试过的分支,第一个种子只有一个分支没有被测过,你的变异想触发这个测试种子的概率要低一些。第二个种子有100个分子,你都要对它变异,更大的概率是触发没有走过的分支,会更快提升覆盖率,这是它背后的想法。

第二个是改进,刚才分支技术这儿只记1,这儿分支后面会跟着一些子路径,也要考虑子路径的数目,计数不再是1,而是把后面的分支根据路径数量加进来。

第三个策略,会考虑到内存访问,我们会统计这个种子所走的路径,基本块访问的数量,会优先排序那些访问数量多的。为什么会这么排序呢?因为我们关注的是内存破坏漏洞,如果你的内存访问操作多,会更大概率地触发内存破坏漏洞的想法,所以,会优先排序。

这样三个策略都有一些改进,看一下实验效果。

第一,是Coverage这边的,代码覆盖率到底提升多少,三个策略,这里分别表示br、desc、memory三个策略,把这个策略加上去之后,路径覆盖率提升20%;如果不加策略,消除碰撞里的效率只提升9.9%,加上br策略它能提升到20%,这是br最好的策略。最后两个策略是对比Fuzz的种子选择策略,我们的方案可以应用在他们上面,所以比他们还是有提升的。

第二,考察挖漏洞的能力,第一个评估是它能找多少crash,这个数量我对比了好几组,包括原始AFL,消除碰撞之后的CollAFL,还加上br策略之后的CollAFL,还有另外几个策略,包括Fuzz还有平均值,100%是7个Fuzz的平均值。平均下来还是br这个策略效果最好,应该有320%的提升。

最后看bug,我们有157个bug在24个开源软件里,其中23个被别人报的,但没有公开,开发者知道。所以,有134个别人没有报过,其中95个我们拿到CVE,没有全部分析完,分析了一部分,其中9个可以阻挡任意代码执行,效果是非常好的。我们这张表里AFL找到51个,br策略找到141个,就是这157个中有141个是br策略找到的。

基本上我的报告就这么多。

结论是,Fuzz是现在比较流行的方法,AFL是代码整合率(音196:10)学术界很多Fuzz是基于这个来做的,如果大家感兴趣,非常建议从AFL开始,因为想法获得实现非常容易。在工业界,他们不是直接把AFL拿过来用,也会进行改进。更多的改进是基于对特定对象的知识,比如Fuzz浏览器,对浏览器也有经验,知道什么叫可触发的漏洞,做一些指导,这个其实很有效。学术界对这个东西没有办法泛化,所以学术界这边没有太多的研究。我们提供了一个CollAFL方案,在AFL上做了更多的改进,消除了它的碰撞,改进了它的种子选择策略,更快地提出代码覆盖率,找到更多的漏洞。

谢谢大家!

主持人潘柱廷:谢谢张超的演讲,张超讲的比较偏学术。今天四位讲者内容各有特色。下面大家还有什么问题可以提问。

Q:张超老师您好,久仰你的大名。我有个问题,AFL我了解的不是特别多,我之前对符号执行那套东西有点了解,2015年开始有个文章开始叫driner(音)把符号执行和AFL做了一个结合,后来这方面的东西我关注的比较少,但一直有个疑惑,想听听您对这个事情的判断,纯做AFL更有前途还是做driner(音)这套更有前途?

宋凯:Driner(音)这个想法是他们UCSB参加CGC方案里一个创新点,这不光是给CGC做补充,我们系统也是类似的方案。非常简单的想法,Fuzz到一定瓶颈的时候,你调节一下就好了,然后再做,用这样简单的方法。那个效果没有想象中那么好,如果你自己实现这个工具,最主要局限在符号执行或者背后的应用场景,UCSB目前那个文件还是个变量(171:35),它对真实程序路径下的约束很多执行不了,这是最讨厌的,目前没有特别好的办法。有些东西有些比较有意思的进展,有工作会把这个符号执行的工作转成Fuzz的工作,有人说Fuzz??(172:05听不清),现在有人说有些场景求不出来的时候扔回来,扔给??(172:10)。总的来说,应用场景是另外一个commit社区在做这个事情,非常困难。??(172:20)很早就有,一九七几年就开始有这个东西,中间一直沉寂,零几年又开始热闹起来,因为零几年计算机开始非常流行。但目前它还是非常有限的,理论上它是很完美的东西,实践中还用不起来,学术界为什么一直不放弃Fuzz呢?因为在很多应用场景下互相没有替代方案,目前在漏洞挖掘利用,CGC是有漏洞利用的,宋凯介绍的是人机来做利用。如果让机器来做这个利用怎么办呢?目前一定要依赖Fuzz,Fuzz在一些应用场景上还是必须的,所以大家一直在探索和改进,如果想有更好效果和收获的话,还是想去改进Fuzz最有效,如果想解决学术上的难题还是需要探索。

本文源自:http://www.cnetsec.com/article/26263.html

本文固定链接: https://www.moondream.cn/?p=933 | 月梦工作室

该日志由 jacky 于2018年09月09日发表在 安全资讯 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 张超:漏洞挖掘的艺术 | 月梦工作室
关键字:

张超:漏洞挖掘的艺术:等您坐沙发呢!

发表评论

快捷键:Ctrl+Enter