一次意外的0day之旅


发布人:admin分类:网络安全浏览量:37发布时间:2017-12-12

不知道大家留意没有,此前百度云安全X-TEAM撰写的文章《技术分析:关于安卓libStagefright系列漏洞分析》中,其实隐含着一个然并卵的0day。这个“0day”,算是我们在构造样本中的副产物。

先看看原始漏洞的情况:在处理mpeg tx3g tag时,chunk_size是64位uint,与size之和溢出,导致实际分配比size小的内存。而后面的memcpy会导致heap overflow,写入的data应该是来自文件内容可控的。

如下是代码:

platform/frameworks/av/+/android-5.1.1_r8/media/libstagefright/MPEG4Extractor.cpp


了解了原理后,我们构造了一个POC,简单地将某个mp4文件中的一个“顺眼的”tagtrak修改为tx3g,于是触发了内存异常。当时还要忙着继续分析就没细看。等到写好文章后发现,这个异常不对啊!怎么还没memcpy就异常了?

于是打开IDA调试一下,结果发现这里的错误实际是一个空指针错误,异常出现在下面text:00063558处,R0=0,读取[R0,#4]发生异常

具体在代码层看,在处理tx3g这个tag时,调用mLastTrack->meta->findData时,metaNULL

原因是meta初始化发生在trak这个tag处理过程中,所以将trak修改为tx3g,恰好就造成一个这个漏洞。

Libstagefright的代码质量有待加强啊。分析patch构造的POC也能变成一个新的0day!虽然看上去很难利用,但请参考下面的链接的猥琐思路:

http://blog.trendmicro.com/trendlabs-security-intelligence/trend-micro-discovers-vulnerability-that-renders-android-devices-silent/

我们也可以构造类似的网页,引入上述mp4,用户一旦访问下面的网页,锁屏后会发现手机几乎无响应,无法点亮屏幕:

而要构造原始的libstagefright的这个漏洞中实际分析的POC,可以按照下面的步骤:

首先要让size>0,否则不会进入后面的memcpy流程,这可以通过两个tx3g来构造。第一个tx3g得到size,第二个tx3g,就可以修改之前的sizeFFFFFF了。

如下图所示,有个trak,然后是两个tx3g,第一个tx3g前面的size正常,第二个tx3g前面的sizeFF FF FF F0,这就造成了溢出。

最终看到的这个异常如下:dlfree已经探测到heap被破坏。

最后给一个利用这个“0day”的视频,这个演示攻击网页还好,要是一个随着开机启动就启动的APP,想想就很开心了……

转载须注明来自FreeBuf黑客与极客(FreeBuf.COM)


被黑站点统计 - 文章版权1、本主题所有言论和图片纯属会员个人意见,与本文章立场无关
2、本站所有主题由该文章作者发表,该文章作者与被黑站点统计享有文章相关版权
3、其他单位或个人使用、转载或引用本文时必须同时征得该文章作者和被黑站点统计的同意
4、文章作者须承担一切因本文发表而直接或间接导致的民事或刑事法律责任
5、本帖部分内容转载自其它媒体,但并不代表本站赞同其观点和对其真实性负责
6、如本帖侵犯到任何版权问题,请立即告知本站,本站将及时予与删除并致以最深的歉意
7、被黑站点统计管理员有权不事先通知发贴者而删除本文

免责声明

本站主要通过网络搜集国内被黑网站信息,统计分析数据,为部署安全型网络提供强有力的依据.本站所有工作人员均不参与黑站,挂马或赢利性行为,所有数据均为网民提供,提交者不一定是黑站人,所有提交采取不记名,先提交先审核的方式,如有任何疑问请及时与我们联系.

admin  的文章


微信公众号

微信公众号


Copyright © 2012-2022被黑网站统计系统All Rights Reserved
页面总访问量:21474722(PV) 页面执行时间:63.309(MS)
  • xml
  • 网站地图