佚名 向大家分享了公开个Nday（图） ,其中包含nday,m0nday,nday动漫,dawn op a new nday,nday漏洞等知识点,遇到此问题的同学们可以参考下
08046估计国内很多小牛大牛搞出来了.最早知道有这么个洞大约是在今年三四月份,听某牛man说有个系统默认支持的图片格式的洞,结果四月份出了个MS08-021,POC也有公开的,当时以为传言指的就是这两个"鸡肋".没想到8月份MS又出了MS08-046,分析过程如下:
先认真看了一遍MS的公告,从公告中可以知道文件格式是EMF,出错模块是MSCMS,具体有漏洞的地方和ICC文件有关系.这样看来PoC应该和MS08-021有点类似.
然后是补丁比较,由于MSCMS模块只有80KB,很快就可以找到出错函数名为OpenColorProfileW,分析出错函数虽然我没有看出有明显的溢出,但知道了该函数主要是通过一个传递过来的文件名(文件名长度要小于104h),在文件名前面补上一个系统目录后再打开这个文件.同时补丁后的功能在处理文件名的时候对长度做了一些处理,所以估计为ICC文件名长度超长所造成的溢出.
第三步构造POC,由于有分析MS08-021的经验,我知道在EMF文件中与ICC文件名相关的Recoder只有几个,在MSDN中都可以搜到,于是写了个GUI程序,然后依次调用GetDC,GetClientRect,CreateEnhMetaFile,SetICMProfileA,CloseEnhMetaFile,ReleaseDC等API构造了一个模版,然后在OpenColorProfileW入口处下断点,就发现在处理SetICMProfileA这个API函数所生成的EMR_SETICMPROFILEA记录时可以走到断点处.但是并不会走到出错的代码块,分析了一下代码流层原来所传入的文件名一是不能超过104h二是文件名的开头必须要以http://开头(怪不得分析08021的时候没找到这个洞).
该写EXP了,由于构造出了POC,也就很容易的发现了出错原理为:在分配存放文件名和路径的内存的时候计算长度是用的lstrlenW,所以造成分配的内存空间只有实际COPY数据的一半,这样就覆盖了后面的堆管理结构及其它一些数据.到这儿漏洞已经可以定性了,就是一个比较标准的堆溢出,在后面的释放或是合并这个堆的时候会造出指针互写的错误,当然由于XPSP2所增加的安全机制,造成这个洞很难利用.不过在IE中有时异常会发生在call [ecx xx]或是mov ecx,[eax](后面是call [ecx xx]),而ECX,EAX为我们传入的文件名转换为UNICODE后的值.再次调试分析后发现:超长串所覆盖的数据中有时会是一个函数指针,而在这个堆释放或是合并之前就会引用这个函数指针.所以一种可能的利用方法就是在IE中用HEAP SPRAY的方法和该漏洞结合.EMF文件中填充的字符串为0040007X(另外为了增大覆盖函数指针的机率你还可以多加几个有超长文件名的记录),或是用JAVA分配内存填充数据为2xXXXXXX.
POC附图:
</div>
先认真看了一遍MS的公告,从公告中可以知道文件格式是EMF,出错模块是MSCMS,具体有漏洞的地方和ICC文件有关系.这样看来PoC应该和MS08-021有点类似.
然后是补丁比较,由于MSCMS模块只有80KB,很快就可以找到出错函数名为OpenColorProfileW,分析出错函数虽然我没有看出有明显的溢出,但知道了该函数主要是通过一个传递过来的文件名(文件名长度要小于104h),在文件名前面补上一个系统目录后再打开这个文件.同时补丁后的功能在处理文件名的时候对长度做了一些处理,所以估计为ICC文件名长度超长所造成的溢出.
第三步构造POC,由于有分析MS08-021的经验,我知道在EMF文件中与ICC文件名相关的Recoder只有几个,在MSDN中都可以搜到,于是写了个GUI程序,然后依次调用GetDC,GetClientRect,CreateEnhMetaFile,SetICMProfileA,CloseEnhMetaFile,ReleaseDC等API构造了一个模版,然后在OpenColorProfileW入口处下断点,就发现在处理SetICMProfileA这个API函数所生成的EMR_SETICMPROFILEA记录时可以走到断点处.但是并不会走到出错的代码块,分析了一下代码流层原来所传入的文件名一是不能超过104h二是文件名的开头必须要以http://开头(怪不得分析08021的时候没找到这个洞).
该写EXP了,由于构造出了POC,也就很容易的发现了出错原理为:在分配存放文件名和路径的内存的时候计算长度是用的lstrlenW,所以造成分配的内存空间只有实际COPY数据的一半,这样就覆盖了后面的堆管理结构及其它一些数据.到这儿漏洞已经可以定性了,就是一个比较标准的堆溢出,在后面的释放或是合并这个堆的时候会造出指针互写的错误,当然由于XPSP2所增加的安全机制,造成这个洞很难利用.不过在IE中有时异常会发生在call [ecx xx]或是mov ecx,[eax](后面是call [ecx xx]),而ECX,EAX为我们传入的文件名转换为UNICODE后的值.再次调试分析后发现:超长串所覆盖的数据中有时会是一个函数指针,而在这个堆释放或是合并之前就会引用这个函数指针.所以一种可能的利用方法就是在IE中用HEAP SPRAY的方法和该漏洞结合.EMF文件中填充的字符串为0040007X(另外为了增大覆盖函数指针的机率你还可以多加几个有超长文件名的记录),或是用JAVA分配内存填充数据为2xXXXXXX.
POC附图:
</div>