基于自適應(yīng)熱補(bǔ)丁的Android內(nèi)核漏洞生態(tài)修復(fù)方案

文/張煜龍　 陳越　包沉浮　夏良釗　鄭龍日　盧永強(qiáng)　 韋韜

基于自適應(yīng)熱補(bǔ)丁的Android內(nèi)核漏洞生態(tài)修復(fù)方案

文/張煜龍 陳越包沉浮夏良釗鄭龍日盧永強(qiáng) 韋韜

學(xué)術(shù)專欄

Android內(nèi)核漏洞嚴(yán)重影響了Android平臺的安全。一旦內(nèi)核被攻破，所有依賴內(nèi)核完整性的安全機(jī)制都岌岌可危（比如加密、進(jìn)程隔離、支付、指紋驗(yàn)證等）。作為Android平臺最后的防線，TrustZone也會受到威脅，因?yàn)閮?nèi)核可以從很多被信任的接口向TrustZone發(fā)起攻擊。因此，理想情況下Android生態(tài)圈應(yīng)該及時消滅內(nèi)核漏洞。然而從Google的Android Security Bulletin上看，Android內(nèi)核漏洞的數(shù)量呈飛快上漲的趨勢（圖1所示）。雖然這代表著人們對內(nèi)核安全的投入逐漸增大，但與此同時這些漏洞一旦公諸于眾，在很長一段時間都難以得到修復(fù)，導(dǎo)致越來越多的可以公開利用的漏洞變成了黑產(chǎn)手中的利器。縱觀近期幾起影響全世界的重大惡意malware事件[1-4]，它們都攜帶了root工具，并且root的方法不是源自公開的PoC，就是直接重用了一些一鍵root工具的庫。

人們經(jīng)常宣稱“Android容易被攻擊”或者“Android不如蘋果安全”。但是，表1列出了幾乎同時期iOS和Android內(nèi)核漏洞數(shù)量的比較，不難發(fā)現(xiàn)Android漏洞公布的頻率甚至不如iOS多。雖然漏洞和漏洞并不能直接拿來比較（因?yàn)槲：Τ潭炔灰欢ㄒ粯樱辽龠@可以提供一個參考基準(zhǔn)——至少蘋果不是生來就安全的，而且也需要定期修復(fù)大量的內(nèi)核漏洞。只是因?yàn)閕OS修補(bǔ)漏洞比較全面和及時，讓人感覺它非常“安全”。同樣地，“Android不安全”并不是僅僅因?yàn)槁┒搭l發(fā)，更重要的還是不能像iOS這樣及時地修復(fù)問題。

為何Android內(nèi)核漏洞得不到及時修復(fù)？

第一，Android的產(chǎn)業(yè)鏈過長：Android生態(tài)系統(tǒng)產(chǎn)業(yè)鏈非常長，從硬件廠商，到Google，到手機(jī)廠商，再到運(yùn)營商。每一個環(huán)節(jié)都有自己的開發(fā)、質(zhì)控、驗(yàn)證等復(fù)雜流程，有時候還會相互沖突。這樣要消耗大量的時間和人力，而且有時甚至導(dǎo)致安全補(bǔ)丁無法下發(fā)給用戶。這個冗長的修補(bǔ)鏈條如圖2所示。

表1

第二，Android系統(tǒng)碎片化過于嚴(yán)重：Android系統(tǒng)的碎片化是指世界上所有Android用戶實(shí)際使用的Android版本、配置、驅(qū)動等等有著非常顯著的差異。Android系統(tǒng)碎片化已經(jīng)成為了業(yè)界共識，由于系統(tǒng)的開源性，用戶、開發(fā)者、OEM廠商、運(yùn)營商都可以按照自己的想法進(jìn)行改造，這種“碎片化”的程度異常嚴(yán)重。在這種情況下，大多數(shù)手機(jī)設(shè)備廠商已經(jīng)失去了為所有用戶使用的Android系統(tǒng)提供安全補(bǔ)丁的能力。圖3所示為繁多的Android品牌和機(jī)型。

圖1

圖2

根據(jù)Google官方發(fā)布于2016年7月的統(tǒng)計(jì)[6]：

1.Lollipop (Android 5.0) 發(fā)布于November 2014， 但是仍然有55% 的設(shè)備低于該版本

2.Google已經(jīng)停止為低于4.4版本的Android提供補(bǔ)丁，但仍有23%的設(shè)備低于該版本

而在中國，由于對Google的訪問被阻隔，這一問題更加嚴(yán)重。通過隨機(jī)采樣大約200萬裝有Baidu App的設(shè)備的手機(jī)，我們發(fā)現(xiàn)：

1.80% 的設(shè)備低于Android 5.0

2.42% 的設(shè)備低于Android 4.4

第三，生態(tài)職能不匹配：其實(shí)最容易推進(jìn)修復(fù)的是手機(jī)廠商，但大部分手機(jī)廠商自身的碎片化現(xiàn)象非常嚴(yán)重，導(dǎo)致了手機(jī)廠商沒有足夠的資源和精力去修復(fù)漏洞。而對于安全廠商來講，修復(fù)漏洞也是一件很尷尬的事情。在正常情況下，安全廠商是沒有系統(tǒng)授權(quán)的，除非先進(jìn)行root。即使root，安全廠商仍然要面臨不同手機(jī)品牌更加嚴(yán)重的碎片化挑戰(zhàn)。

案例分析

具體看3個著名的能被用來進(jìn)行跨平臺root的漏洞：第一個是CVE-2014-3153（Towelroot），公開和修補(bǔ)時間為June 3, 2014[7]；第二個是CVE-2015-3636（Ping Pong Root），公開和修補(bǔ)時間為 September 9, 2015[8]；第三個是CVE-2015-1805，公開時間為April 3, 2014[9]，但直到March 18, 2016才在Android平臺上修復(fù)[10]。圖4 所示為這三個漏洞距今（2016年7月）的時間跨度。其中最短的也達(dá)到了120天。

圖5 所示為這三個漏洞在裝有百度App的手機(jī)上的隨機(jī)采樣結(jié)果。可見雖然這么長時間過去了，仍然有非常多的設(shè)備沒有得到漏洞修復(fù)。

AdaptKpatch: 自適應(yīng)內(nèi)核熱修補(bǔ)框架

如何解決Android漏洞得不到及時修補(bǔ)的問題？對于跳過冗長補(bǔ)丁鏈這個問題，學(xué)術(shù)界工業(yè)界已經(jīng)給出了一些方案，比如kpatch[11], ksplice[12], kGraft[13], Linux upstream的livepatch[14]，但是這些方案并沒有解決碎片化和能力失配的問題。更本質(zhì)地說，這些方案都依賴源碼，對于沒有源碼的第三方不適用，更遑論補(bǔ)丁的廣泛適配。因此在第七屆HITB 會議上[15], 我們提出了內(nèi)核自適配修補(bǔ)的方案，稱作AdaptKpatch。其大致流程如圖6所示。

簡單來說，該框架在手機(jī)上探測存在的內(nèi)核漏洞，向用戶征詢是否修復(fù)。得到允許后，該框架root手機(jī)并收集必要的信息，包括kernel versions, symbol addresses, symbol CRCs等。取決于設(shè)備是否提供insmod或者(k)mem 設(shè)備，框架會下載對應(yīng)的模板進(jìn)行數(shù)據(jù)結(jié)構(gòu)填充和symbol解析，并視情況對內(nèi)核的一些動態(tài)校驗(yàn)機(jī)制進(jìn)行放寬。這些步驟完成后即完成補(bǔ)丁模板的適配，所生成的補(bǔ)丁即可插入該設(shè)備的內(nèi)核執(zhí)行修補(bǔ)操作。具體的修補(bǔ)操作和其他熱修補(bǔ)方案無異，比如函數(shù)替換、調(diào)用替換、原地修補(bǔ)等，此處不再贅述。 注意該框架只是熱修復(fù)，因此每次重啟都要重新加載熱補(bǔ)丁。如果某次啟動發(fā)現(xiàn)前次啟動因?yàn)闊嵫a(bǔ)丁而出現(xiàn)崩潰，則放棄加載熱補(bǔ)丁回滾到正常啟動。

圖3

圖4

圖5

圖6

如果手機(jī)廠商愿意和第三方協(xié)作修復(fù)時，該框架可以最大化發(fā)揮效益。廠商不再需要花資源和精力修補(bǔ)漏洞，只需要提供預(yù)制的內(nèi)核修補(bǔ)機(jī)制/能力，而安全廠商不需要再root手機(jī)和探測漏洞，可以專注在修補(bǔ)漏洞上。這一合作模式如圖7所示。基于這一合作聯(lián)盟，可有如下安全機(jī)制保證補(bǔ)丁的安全。

1.廠商資質(zhì)校驗(yàn)：只有有能力和名聲好的廠商方可進(jìn)入合作聯(lián)盟，各廠商所發(fā)補(bǔ)丁需簽名驗(yàn)證；

2.補(bǔ)丁審計(jì)：補(bǔ)丁發(fā)放前需要經(jīng)過聯(lián)盟里別的廠商進(jìn)行安全審計(jì)，防止引入新的漏洞或者后門；

3.評價(jià)排名：類似于App Store，用戶可以對某個補(bǔ)丁進(jìn)行穩(wěn)定性等方面的評價(jià)。其他用戶可以根據(jù)補(bǔ)丁的既有評價(jià)選擇打還是不打。

LuaKpatch: 更靈活迅速，但是更嚴(yán)格

設(shè)計(jì)原理

AdaptKpatch已經(jīng)能很好地解決Android內(nèi)核漏洞長期得不到修復(fù)的問題了，但補(bǔ)丁仍然需要通過審計(jì)才能保證安全。因此我們還提出了另一個方案：LuaKpatch。其原理是用類型安全（type-safe）的動態(tài)語言引擎（比如Lua）來執(zhí)行補(bǔ)丁。這樣一來補(bǔ)丁靈活易維護(hù)，同時其執(zhí)行可以嚴(yán)格控制在引擎所允許的范圍內(nèi)，也不擔(dān)心因?yàn)橐绯觥⒖罩羔樢玫葐栴}被攻擊劫持。

圖7

圖8

圖9

圖8 所示為絕大部分kernel漏洞攻擊的原理。一般而言攻擊者都需要灌入惡意的輸入來實(shí)現(xiàn)控制流劫持。因此LuaKpatch只需要在函數(shù)入口和函數(shù)中讀數(shù)據(jù)的位置插入檢查即可，不需要給予補(bǔ)丁任意hook的能力。

具體來說，我們有如下限制：

1.補(bǔ)丁可以hook函數(shù)入口，檢查參數(shù)和環(huán)境。

2.補(bǔ)丁也可以hook函數(shù)中的調(diào)用，前提是該調(diào)用返回的是狀態(tài)值（下文只有條件依賴），而不是指針等有數(shù)值依賴的返回值（copy_from_user滿足這一條件，返回是成功或失敗的狀態(tài)值）。

3.補(bǔ)丁可以任意讀，但不可寫，更不能發(fā)送數(shù)據(jù)出去。

4.補(bǔ)丁完成條件判斷后，可返回正常或異常。這樣當(dāng)遇到攻擊輸入時，內(nèi)核隨后的執(zhí)行不會觸及會被exploit的代碼。

為了更直觀地理解，圖9給出了一個具體的例子。fun調(diào)用了foo 和bar。其中fun的入口是允許被hook的，fun中foo的調(diào)用前和調(diào)用后也是允許被hook的，因?yàn)閒oo返回值只有條件依賴，而bar是不能被hook的，因?yàn)橄挛漠a(chǎn)生了數(shù)值依賴（其中一個域被用作函數(shù)指針進(jìn)行調(diào)用）。這樣一來，攻擊者即使控制了補(bǔ)丁，也沒法通過返回惡意數(shù)值來實(shí)現(xiàn)任意代碼執(zhí)行。

我們?yōu)榉祷刂抵挥袟l件依賴的函數(shù)生成了一個白名單，對于一個目標(biāo)函數(shù)，其調(diào)用只有在落在這個集合里時才能被hook檢查。而且注意hook發(fā)生在目標(biāo)函數(shù)調(diào)用處，而不是被調(diào)用函數(shù)的入口和返回處。我們稱能在函數(shù)口作檢查即可修復(fù)的漏洞為Type I vulnerabilities，而如果還需要在函數(shù)體內(nèi)對調(diào)用做hook檢查的，則稱為Type II vulnerabilities。稍后我們會給出兩種漏洞的數(shù)目。

圖10

表2

圖11

實(shí)現(xiàn)

我們基于Lua實(shí)現(xiàn)了LuaKpatch，為了將Lua集成在內(nèi)核里，很多改變借鑒了lunatik-ng[16]. 比如數(shù)值應(yīng)該修改為整型而非浮點(diǎn)型。LuaKpatch的代碼大約1萬1千行，其中核心的與修補(bǔ)有關(guān)的代碼大概600行。編譯后LuaKpatch模塊大小為800KB。廠商可以提前將這一模塊集成于內(nèi)核里，或者可以借用AdaptKpatch里所介紹的內(nèi)核模塊自適應(yīng)加載方法，后天由第三方root手機(jī)后插入內(nèi)核。

LuaKpatch為Lua形式的內(nèi)核補(bǔ)丁提供了如下接口：符號搜索、hook（在指定位置插入trampoline，保存現(xiàn)場并調(diào)用Lua補(bǔ)丁的handler進(jìn)行判定，然后回到指定位置的下一指令）、內(nèi)存讀取、thread信息獲取。 圖10 為利用LuaKpatch修補(bǔ)Towelroot漏洞的實(shí)例。

有效性分析

如表2所示，近年幾乎有代表性的能用來root手機(jī)的內(nèi)核漏洞LuaKpatch都能修補(bǔ)。前面提到的能在函數(shù)口作檢查即可修復(fù)的漏洞為Type I vulnerabilities，而如果還需要在函數(shù)體內(nèi)對調(diào)用做hook檢查的，則稱為Type II vulnerabilities。圖11提供了這兩類漏洞的比例，大部分漏洞還是可以簡單地通過在函數(shù)口進(jìn)行檢查來修補(bǔ)的。萬一遇到LuaKpatch不能修補(bǔ)的漏洞，可以回滾到AdaptKpatch方案進(jìn)行修補(bǔ)。

性能測試

我們用CF-Bench[17]在裝有Android 4.4的Nexus 5 上測了四種情況：不打補(bǔ)丁，用LuaKpatch修補(bǔ)Towelroot，用LuaKpatch修補(bǔ)Ping Pong Root，用LuaKpatch修補(bǔ)二者。 結(jié)果如圖12 所示——LuaKpatch完全沒有帶來任何性能損耗。這是預(yù)料之中的，因?yàn)樘釞?quán)內(nèi)核漏洞往往出現(xiàn)在平時無法觸及的執(zhí)行路徑上，修補(bǔ)后并不對正常執(zhí)行產(chǎn)生影響。

圖12

圖13

圖14

盡管如此，我們還是想知道一旦被觸及，LuaKpatch的開銷是多少。因此我們測試了chmod 系統(tǒng)調(diào)用的原始執(zhí)行時間、打上補(bǔ)丁但是補(bǔ)丁直接return的執(zhí)行時間（相當(dāng)于只是現(xiàn)場保存恢復(fù)和Lua進(jìn)出的開銷）、打上補(bǔ)丁且補(bǔ)丁做一次條件判斷的執(zhí)行時間、打上補(bǔ)丁且補(bǔ)丁做一次內(nèi)存地址讀的執(zhí)行時間、打上補(bǔ)丁且補(bǔ)丁做一些列綜合操作（變量操作、內(nèi)存讀、條件判斷等，模擬一個比Towelroot和Ping Pong Root補(bǔ)丁更復(fù)雜的補(bǔ)丁的操作）的執(zhí)行時間，其結(jié)果如圖13所示。可見即使在復(fù)雜補(bǔ)丁的執(zhí)行下，也只多了3.74微秒的開銷。這僅僅是chmod正常執(zhí)行的4%。

基本上，在我們的測試?yán)铮琇uaKpatch補(bǔ)丁都能在5微秒的開銷里完成任務(wù)。未來會把LuaKpatch的引擎換成LuaJIT[19]，性能會得到進(jìn)一步提升。

基于本文所述AdaptKpatch和LuaKpatch技術(shù)，Android修補(bǔ)流程可以改進(jìn)成如圖14所示。對于非常嚴(yán)重的問題、需要幾天內(nèi)推出補(bǔ)丁的，可以用LuaKpatch；對于LuaKpatch不能解決的問題，可以經(jīng)過補(bǔ)丁審計(jì)后用AdaptKpatch方案推出；最終冷補(bǔ)丁可以永久性地修補(bǔ)相應(yīng)問題。基于這一流程，Android內(nèi)核漏洞長期難以被修復(fù)的問題可以得到妥善解決。

我們呼吁Android生態(tài)圈建立一個開放協(xié)作的聯(lián)盟，包括手機(jī)廠商、安全廠商和其他Android社區(qū)的成員。這個聯(lián)盟將具有非常重要的意義：

一是漏洞越來越多也越來越復(fù)雜，在LuaKpatch和AdaptKpatch提供的和作平臺上，大家可以分擔(dān)修補(bǔ)的難題，共享其成；

二是對于AdaptKpatch的場景，越多的參與者意味著更多更安全的補(bǔ)丁審計(jì)；

三是整個Android生態(tài)圈應(yīng)該一起將這個熱修補(bǔ)流程維護(hù)成統(tǒng)一的標(biāo)準(zhǔn)，防止在當(dāng)前設(shè)備碎片化之上又引入了修補(bǔ)方案的碎片化，導(dǎo)致最終還是各方分散力量修補(bǔ)漏洞、難以規(guī)模化有效地解決問題。

[1] http://www.cmcm.com/blog/en/security/2015-09-18/799. html

[2] https://www.fireeye.com/blog/threat-research/2015/10/ kemoge_another_mobi.html

[3] https://www.bluecoat.com/security-blog/2016-04-25/ android-exploit-delivers-dogspectus-ransomware

[4] https://blog.checkpoint.com/wp-content/uploads/2016/07/ HummingBad-Research-report_FINAL-62916.pdf

[5] http://opensignal.com/reports/2015/08/androidfragmentation

[6] https://developer.android.com/about/dashboards/index.html

[7] https://github.com/torvalds/linux/commit/e9c243a5a6de0be 8e584c604d353412584b592f8

[8] https://source.android.com/security/bulletin/2015-09-01. html

[9] https://github.com/torvalds/linux/commit/f0d1bec9d58d4c0 38d0ac958c9af82be6eb18045

[10] http://source.android.com/security/advisory/2016-03-18. html

[11] https://github.com/dynup/kpatch

[12] https://www.ksplice.com/doc/ksplice.pdf

[13] http://events.linuxfoundation.org/sites/events/files/slides/ kGraft.pdf

[14] http://lxr.free-electrons.com/source/include/linux/ livepatch.h

[15] https://conference.hitb.org/hitbsecconf2016ams/sessions/ adaptive-android-kernel-live-patching

[16] https://github.com/lunatik-ng/lunatik-ng

[17] https://play.google.com/store/apps/details?id=eu.chainfire. cfbench&hl=en

[18] https://httpd.apache.org/docs/2.4/programs/ab.html

[19] http://luajit.org