淺談微軟瀏覽器IE漏洞


CVE-2014-6332神洞為例

大家好! 我是 沈家生

網路代稱 : HrJ

VSSecurity 資安顧問

TDOHacker  北區召集人/總召

感謝許教授邀請我來健行科大演講

今天要與各位淺談......

CVE-2014-6332

 MS14-064

IE 神洞

漏洞影響範圍

  • win 95 ~ win 10
  • IE 3 ~ IE 11

漏洞介紹

本次漏洞主要是利用  VBscript 的陣列錯位方式

將 IE 中原本因為被 safe mode 限制而權限很低的 VBscript

繞過 safe  mode 的限制

變成可以執行任意指令

所以就可以玩很多種不同的攻擊了 

(EX: 開啟記事本 、 新增系統管理員級的帳號)

更好玩的是!!

這其實不能算是 IE 的漏洞

但是這漏洞卻發生在 IE 非常依賴的 VBscript

先來講點背景知識

在 IE 瀏覽器中

  • VBscript是受限制、權限低
  • 這限制是利用 safe mode flag值 來控制
  • 正常情況在 safe mode 下這變數值應該是 0x0E 

但如果遭修改成 0x00

就可以讓 VBscript 執行任意指令

漏洞應用層面

我們重點不在 shellcode 或是 其所在記憶體的分配與控制

而是專注於更改 safe mode flag值 

所以才能在 IE3 ~ IE11 下全面通殺

同時繞過微軟相關的保護措施 (DEP、ASLR、EMET、CFI ...等)

漏洞成因

SafeArrayRedim 函數中有一條邏輯分支是 :

  • 定義一個陣列 a , 長度維 0x30 當使用 redim preserve 重新定義該陣列時,如果長度維 0x20 ,就會根據 (0x20-0x30)的值來申請記憶體空間,並將 0x30 中多餘的數據移到這空間上,而不是將後面的數據丟掉
  • 並且在做最小長度 - 最大長度時,判對差值是使用有符號比較
  • 如果當newarray 的長度 - lodarray 長度差值是 0x8000000 ,但使用該值無法申請這麼大空間時,由於 VBscript 的on error resume next 的原因

  •  newarray 結構中的元素長度會被修改,而buf的基準位址不變。

漏洞的觸發

   

  1. VBscript 變數結構

  • 每個 VBscript 變數在記憶體中占用 0x10 bytes
  • 其定義是 variant 結構
  • 前兩個字節是 vartype vt 用來標示變數類型 (EX:VT_BSTR = 8表示 String 類型的 bstr )
  • 而在這結構中 cElements 代表陣列的元素長度
Dim aa(0xbb)

cElements = 0xbb + 1

length = (0xbb + 1) * 0x10

pvData = alloc(length)

2.  redim 解釋

  • redim 是用來重新分配陣列的記憶體空間
  • 如果加上 preserve ,就是我們可以修改最後一個維度大小,也就是  cElements 的值
  • 當漏洞觸發後因為無法申請0x8000000大小的 pvData出錯但又因為 VBscript 的容錯機制(on error resume nex),所以 pvData 沒被改變,但是 cElements 變了

漏洞目的與利用

這漏洞最終目的其實是開啟 “God mode (上帝模式)”

其實就是改掉 safe mode 的 flag

所以這漏洞要成功有三個關鍵點:

  1. 一個只是改寫元數長度的陣列
  2. 可操控的目的記憶體位址
  3. 可操控的寫入資料

越界判定

  • 在一般正常的陣列中,正常是不能越界訪問的
  • 漏洞造成結果是 safesarray 中的 cElement 被改成一個很大的值 0x800000X
  • 但是 pvData 卻沒被改變,導致我們可以訪問一個索引比  0x800000X小的值
  • 而當我們要索引陣列中的資料時,會使用 AccessArray函數,利用比較索引值來判斷是否越界

越界開啟

redim Preserve aa(a2)

利用更改 cElements 造成的索引值去越界

 

越界關閉

 

redim Preserve aa(a0)

把  cElements 改成正常值,就不能越界了

越界訪問

aa 陣列的 pvData 起始位址是 0x1a7810

ab 陣列的 pvData 起始位址是 0x1a78b8

正好差(9+1)*16 + 8

越界之後的一組data如下:

aa(11) > 0x1a7810 + 0xb*0x10 = 0x1a7810+0xb0 = 0x1a78c0

ab(0) > 0x1a78b8+0*0x10 = 0x1a78b8

從這邊我們可以看到 aa(11) 讀到了 ab(0) 空間的內容了

這也是為什麼修改索引值我們可以越界讀取的原因

尋找可操控的目的記憶體位址

兩個全域陣列連續定義時,

有可能這兩個safearray對象的pvData位址在記憶體上也是連續的
On Error Resume Next

redim  Preserve aa(a2)  

  

ab(0)=0   

aa(a1)=add+4     

ab(0)=1.69759663316747E-313       

ReadMemo=lenb(aa(a1))  

ab(0)=0    

 
redim  Preserve aa(a0)

redim   ab(a0)

全域陣列 aa() & ab () 連續定義

雖然目標是連續定義,但是不一定真的是連續的,所以我們會使用迴圈來提高機率

當 Over 函數返回 Ture 的時候,就可以確定兩個是連續的

For i = 0 To 400

	If Over() - Ture Then

		Creat-Ture

		Exit For

	End if

Next
假設執行了:

dim aa(9)

dim ab(9)

那在記憶體中則會

連續的記憶體位址

假設:

ab的pvData的位址:0xBBBBBBBBB

aa的pvData的地址:0xAAAAAAAA

0xBBBBBBBBB – 0xAAAAAAAA = aa的pvData的長度 + 8 bit 的 stack 

 

而 aa 的計算如下:

Length = cElements * 0x10

pvData = alloc(Length )

也就是說~我們可以精確的使用越界的 aa 來讀取 ab

驗證 pvData stack 是否連續

  • 由於 pvData stack分配時,會將其都清為 0
  • 驗證連續的原理是:使用一個很大的浮點數來當一個 flag ,把這個 flag 放到 ab(0) 上。
  • 當 aa 越界訪問指定偏移的data,如果剛好是 ab(0)的內容,那麼就能說明 aa 和 bb 有姦情已經連續排列
  • 驗證過程中也是用了 stack 頭作判斷

aa的pvData是0x1a7810,最後位址0x1a7810 + 9*0x10 =0x1a78a0

ab的pvData是0x1a78b0,最後位址0x1a78b0 + 9*0x10

抓出自定義函數的目標

當兩個連續目標的pvData在記憶體中連續排列後

我們要做的就是把函數目標的位址也抓出來

該位址可以用在後面 safe mode 定位

抓取地址

得到一個函數 variant 的目標後,將該目標都有 aa(a1),然後經由 ab(0) 修改 aa(a1) 的資料類型為 VT_I4,然後利用 aa(ad)把位址讀出來。

任意位址讀取

ReadMemo函數是用來給特定的參數去 add 讀取其內容,也就是可以讀取任意地位址的內容

ReadMemo(add) = poi(add)

 

safe mode 地址定位

前面已經說明利用 testaa 函數,目標的位址已經被抓出來,而且我們來能任意讀,而 safe mode 的位址可以通過 testaa 被抓取出來。

任意位址寫入

前面經過一大堆亂七八糟的手法,我們終於到最重要的地方了 !

小結:

aa(a1+2)(i+&h11c+k)=ab(4)

> 往i+&h11c+k計算結果中寫入ab(4)的資料,i+&h11c+k不僅僅是個索引值,還是一個目標的位址,因為i+&h11c+k是可控制的

所以可在任意位址寫入 Data,但是這只有在設計過的 aa(a1+2 下才會成立)

潛在危險與該如何防範

  • XP 與 其他就系統沒有更新
  • IPS / 網路安全套裝軟體可能可以進行虛擬修補
  • 將系統更新到最新
  • 不要用 IE

Q & A

參考資料

來源 : 

http://www.freebuf.com/vuls/51628.html

http://www.freebuf.com/articles/system/51501.html

http://www.venustech.com.cn/UserFiles/20141210_%E6%97%A0%E9%9C%80%E6%8B%85%E5%BF%83%E6%BD%9C%E8%97%8F%E4%BA%8618%E5%B9%B4%E7%9A%84%E5%BE%AE%E8%BD%AF%E6%B5%8F%E8%A7%88%E5%99%A8%E8%BF%9C%E7%A8%8B%E4%BB%A3%20%E7%A0%81%E6%89%A7%E8%A1%8C%E6%BC%8F%E6%B4%9E.pdf

http://xteam.baidu.com/?p=104

http://blog.vulnhunt.com/index.php/2014/11/18/about_cve-2014-6332/http://blog.vulnhunt.com/index.php/2014/11/18/cve-2014-6332-used-in-targeted-attack/

 

淺談 CVE-2014-6332

By hrjk

淺談 CVE-2014-6332

  • 3,917