為了提升Android系統(tǒng)的安全系數(shù)，我們一直歡迎并獎(jiǎng)勵(lì)任何發(fā)現(xiàn)漏洞的研究者。比如，2015年，mediaserver的libstagefright中被發(fā)現(xiàn)了一系列漏洞，我們?cè)谕?月和9月的安全公告（Security Bulletin）中對(duì)此進(jìn)行了更新。
　　除了每月解決這些問(wèn)題，我們還在開(kāi)發(fā)新的安全功能來(lái)強(qiáng)化現(xiàn)有安全模式，并提供額外的深度防護(hù)措施。防護(hù)措施主要有兩個(gè)目標(biāo)：
　　防護(hù)：防止漏洞；
　　遏制：通過(guò)降低優(yōu)先等級(jí)及隔離不信任內(nèi)容相關(guān)組件來(lái)保護(hù)系統(tǒng)。
　　防護(hù)（Prevention）
　　libstagefright中大部分漏洞都是無(wú)符號(hào)整數(shù)溢出（integer overflows）導(dǎo)致的堆棧溢出。且libstagefright的多個(gè)整數(shù)溢出讓攻擊者可以分配不為輸入數(shù)據(jù)提供足夠空間的緩沖區(qū)，導(dǎo)致堆棧中出現(xiàn)緩沖區(qū)溢出。
　　無(wú)符號(hào)整數(shù)溢出的后果已有清晰定義，但接下來(lái)的操作可能產(chǎn)生無(wú)法預(yù)料的風(fēng)險(xiǎn)。相比之下，有符號(hào)整數(shù)溢出在C/C++語(yǔ)言中未被定義，意味著不能保證溢出產(chǎn)生的結(jié)果，而編譯者可能選擇典型最快最簡(jiǎn)單的操作。我們已經(jīng)調(diào)整了編譯器，為有符號(hào)和無(wú)符號(hào)整數(shù)溢出均提供更加安全的預(yù)設(shè)值。
　　UndefinedBehaviorSanitizer（UBSan）是檢測(cè)非定義或錯(cuò)誤操作的LLVM/Clang編譯器工具鏈。UBSan可以檢查有符號(hào)和無(wú)符號(hào)整數(shù)溢出等多種非定義和不安全操作，在此過(guò)程中會(huì)在執(zhí)行時(shí)間為產(chǎn)生的可執(zhí)行的整數(shù)溢出條件測(cè)試添加新代碼。比如圖1顯示的是：研究者提供的原始補(bǔ)丁應(yīng)用之后，libstagefright中的MPEG4Extractor組件的parseChunk源代碼。底下黑框里的修改內(nèi)容是為了防止整數(shù)溢出。
　　
　　圖1 源代碼中難以察覺(jué)的無(wú)符號(hào)整數(shù)溢出
　　可惜SIZE_MAX和size為32位，而chunk_size是64位的，有可能出現(xiàn)檢查不徹底，存在整數(shù)溢出的情況。紅框里的size + chunk_size可能導(dǎo)致整數(shù)溢出，以及產(chǎn)生比size elements更小的緩沖區(qū)。因?yàn)閟ize + chunk_size可能比藍(lán)框標(biāo)注出來(lái)的size更小，所以接下來(lái)memcpy可能導(dǎo)致內(nèi)存崩潰。關(guān)于該漏洞潛在exploit vector的更多信息請(qǐng)參考Project Zero。
　　圖2將以上代碼片段產(chǎn)生的集合與第二個(gè)帶有整數(shù)凈化的編譯版本進(jìn)行比較。紅框里的是引發(fā)整數(shù)溢出的添加操作。在未凈化版本中，size （r6）和chunk_size （r7）是一起添加的，可能導(dǎo)致r0溢出，且小于size。然后緩沖區(qū)分配到規(guī)定的r0 size，size字節(jié)被復(fù)制上去。如果r0小于r6，就會(huì)出現(xiàn)內(nèi)存崩潰。