0x00 前言

---

這是Project Zero上的文章，原文為《Taming the wild copy: Parallel Thread Corruption》

連結: http://googleprojectzero.blogspot.com/2015/03/taming-wild-copy-parallel-thread.html

2002年，Apache Web伺服器中發現並修復了一個非常有趣的漏洞。伺服器在處理分塊傳輸編碼時存在缺陷，漏洞將導致memcpy()呼叫的長度為負值，且目標緩衝區在堆疊上。當然，很快許多人就宣佈這一漏洞是不可利用的，只能造成拒絕服務。畢竟memcpy()函式呼叫時長度欄位採用負值，將導致巨大的記憶體空間複製，肯定會命中一個未對映的記憶體頁導致程式終止。由於FreeBSD和其他BSD衍生版本在memcpy()實現上的一些特性，出現了可用的遠端程式碼執行漏洞利用程式，讓人感到了驚喜！ GIAC文章 LINK 記錄了漏洞利用程式碼，並分析了它是如何工作的（GIAC文章的附錄D中）。

為了清楚的描述這篇文章的目的，我們將wild copy定義為滿足下面兩個條件的記憶體複製：

• 攻擊者對記憶體複製的長度擁有有限的控制權。

• 記憶體複製的長度總是能夠導致對未對映頁的訪問。

在許多其他有趣的情況下，wild copy型漏洞最終可以被利用：

• 針對Windows結構化異常處理程式（SEH）的攻擊。

• 不止BSD衍生版本上存在類似memcpy()特性的問題。 2011年，在Ubuntu上eglibc漏洞 LINK 是由於對memcpy()函式的呼叫採用了任意的長度欄位。memset()變體漏洞 LINK 透過Chromium漏洞獎勵計劃被披露。

• Java執行時環境中安裝了非常複雜的崩潰處理程式，當wild copy不可避免地觸發訪問異常時被呼叫。在堆狀態任意損壞的情況下，如果崩潰處理程式不夠健壯，它自身可能會崩潰，導致漏洞更加可控和可利用。

上述所有情況都有一個共同點：wild copy漏洞可利用性由次要問題（secondary issue）或特性導致。

是否有可能利用wild copy漏洞，而不依賴於次要問題？這是Project Zero要解決的一個有趣問題 -- 當我們探索漏洞利用時，我們可以更加了解問題，或者推動利用技術的發展。今天，我們要探索64位Linux上，Chrome的Flash外掛的wild copy漏洞。

現在是時候引入問題122 和“parallel thread corruption”。問題122是一個Adobe Flash漏洞，2014年11月被修復，這是一個奇怪的錯誤，在一些平臺上G711聲音編解碼器發生了錯誤，編解碼器在試圖解碼一些樣品時總是導致wild copy。漏洞觸發時，會導致memmove()呼叫使用負值作為長度引數。在現代Linux系統中，memmove()的實現似乎沒有問題，而SIGSEGV處理程式乾淨的清理了程式。現在來看看我們所做的工作！

0x01 選擇方法

---

我們要去嘗試“parallel thread corruption”，也就是線上程A中觀察和利用執行緒B的非同步記憶體破壞.執行緒B的記憶體破壞總是會導致崩潰，我們需要並行執行兩個執行緒。還需要贏得一個棘手的競爭條件：線上程B奔潰導致執行緒A退出前獲取程式碼執行.

我們將試圖讓記憶體破壞漏洞破壞Vector.\