作者:qever
昨晚驚聞Stagefright爆出重大漏洞，可以造成遠程代碼執行，甚至發條彩信，就有可能入侵用戶移動設備。這聽起來可是難得一遇的大漏洞啊，作為安全人員，自然要好好扒一扒內幕了。
從新聞來看，出于某些考慮，漏洞的發現者目前并沒有公布相關的細節，而是決定要留到BlackHat上再進行詳細的說明。也就是說，目前所知道就是Android系統的Stagefright庫存在重大安全問題，具體是什么？想知道自己去Fuzz。
雖然，看起來關于漏洞細節，并沒有任何頭緒。但是，作為安全人員，首先要堅信的一點，就是世界上沒有不透風的墻！仔細研讀漏洞的新聞稿，可以發現，該漏洞已經提交給了Google，并且Google迅速的進行了修復。同時發現，Google也已經把漏洞相關信息交給了部分合作伙伴。看完這些，就能確定，這漏洞目前還能扒。
既然Google針對此漏洞，已經在源碼中進行了修復。那么首先查看了Google的相關源碼提交狀態。
簡單翻閱了提交的log。發現了一些關于libstagefright安全問題的修復，但大多言簡意賅，難以確定。
看起來從Google方面下手并不容易，好在Google已經將漏洞相關資料交給了合作伙伴，所以我們發現了CyanogenMod公布的一條消息。
也就是說，在CM12中已經對此漏洞進行了修復！
隨后，我們在github上找到了CM12的提交記錄
可以看到，在CM12的最近提交中，都是對Stagefright相關漏洞的修復，根據這些修復內容，對漏洞大體上也就能有一些了解了！
我們對部分修復方案進行了簡單分析。
Bug: 20139950
該bug的位置在frameworks/av/media/libstagefright/SampleTable.cpp文件的SampleTable::setSampleToChunkParams函數中，從該bug的說明和修復上來看。是由于mNumSampleToChunkOffets值太大，可能造成溢出。相關代碼如下
注意紅線標注部分。可能會造成訪問越界。從而引發安全問題。
mSampleToChunkOffset 是類SampleTable的成員變量，在SampleTable::setSampleToChunkParams中進行初始化，用于記錄數據偏移。當mNumSampleToChunkOffsets設定為非法值的時候，就會造成readAt的時候，越界讀取。
根據目前的分析，該漏洞目前并不能造成安全攻擊。主要原因在于讀取到的數據只是用于成員變量的賦值。由于本來就是要從文件中讀取數據，所以實際上buffer內容是可控的，因為該漏洞本身沒有什么安全意義，只是為了保證系統穩定性的patch。
Bug: 20139950
該bug在frameworks/av/ media/libstagefright/ESDS.cpp的ESDS::parseESDescriptor函數中。直接從描述和修復代碼中，就能看出來，是由于在解析過程中，對變量校驗不嚴格，可能造成越界訪問的問題。此問題并不是重點，也就不細說了。
Bug: 20923261
此漏洞產生于frameworks/av/media/libstagefright/MPEG4Extractor.cpp的MPEG4Extractor::parseChunk函數中。從截圖就可以看到漏洞的全貌了。當chunk_data_size小于kSkipBytesOfDataBox時，紅線部分就會變成一個負數，由于setData的最后一個參數類型是size_t，所以就會被解析成很大的正數，從而造成錯誤。
其余的漏洞，大部分都是相似的原因，對讀取的數據校驗不嚴格造成解析錯誤。這種問題一般只能造成進程崩潰，并無法引起嚴重的安全問題，除非……
看過上面列舉的例子，難免有種感覺，所謂的Stagefright可能就是在危言聳聽，因為大部分漏洞看起來都只是開發人員的一個小疏忽。直到我們遇到了TA……
從這份提交的注釋里面，我們就能看到一些關鍵詞，例如”potentially exploitable condition”。那么這個”condition”是如何產生的呢？從注釋里面可以看到，是當chunk_data_size的值為SIZE_MAX的時候，會發生溢出。
chunk_data_size是一個可控的變量，來源就不多說了。我們只關注漏洞成因。
在類Linux系統下，SIZE_MAX一般為((size_t)-1)，也就是我們常見的0xFFFFFFFF(32位)，當chunk_data_size== SIZE_MAX的時候。chunk_data_size + 1的值就會為0（不要問我為什么 =。= ），下一句代碼
由于chunk_data_size + 1 = 0，就會造成buffer申請的內存空間為0。
之后，通過mDataSource->readAt函數，將指定內容讀取到buffer所申請的內存中。
可是！buffer實際申請的內存大小為0！也就是說，readAt會造成寫越界，從而寫系統數據，達到攻擊的目的！！
由于該漏洞尚未被修復，我們的文章也就到此戛然而止了。值得一提的是，同樣的問題，在同一個文件中，不止一次的出現。
更多的細節，就留給各位慢慢挖掘吧。
由于時間水平有限，本文僅僅從patch的角度，分析了可能產生攻擊的點。此漏洞畢竟影響很大，而且尚未被修復，本身不宜公布更多的細節，所以有些地方言語不詳，希望能夠理解。
概覽全部的修復代碼，發現產生漏洞的原因，都是因為對數據校驗完善造成的。此次曝光的只是Stagefright的問題。考慮到Android系統中包含了大量的文件解析代碼，包括圖片、壓縮包、音頻、視頻等解碼庫。這些庫在解析文件過程中，對數據進行嚴格的校驗了嗎？會不會明天又會爆出音頻解碼存在嚴重bug？這應該是值得開發者和安全從業者深思的問題。
由于此漏洞不宜講太深入，造成之前描述太過于模糊，且很多地方不準確。所以引起了一些質疑。
最后放上一個POC吧，打開文件會解析錯誤。由于單純從解析錯誤，無法證明觸發了漏洞，所以添加了一些Log作為輔證。
該截圖重點在于buffer指向地址0xb8a93fe0，但是size卻為0。后面覆蓋之前buffer指向地址的內容是”F0 31 EC B6”，覆蓋之后變為”12 34 56 78”，覆蓋的長度為”x = 0x40020”。
熟悉細節的朋友也可以從mp4文件中尋找到相關修改。
最后，此mp4文件來源于網絡，10+M大小，mp4格式……了解漏洞細節的，可以自行修復mp4文件，然后觀看其內容。（你們懂的 =。=）