如何用幾行代碼打造應(yīng)用程序熱補(bǔ)丁？（二）
一、前言
在《如何用幾行代碼打造應(yīng)用程序熱補(bǔ)丁?(一)》中，我們介紹了應(yīng)用程序熱補(bǔ)丁技術(shù)的基本原理，同時(shí)實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的熱補(bǔ)丁。但是無法對(duì)本地函數(shù)打熱補(bǔ)丁，同時(shí)手動(dòng)編寫熱補(bǔ)丁比較麻煩、可能非常復(fù)雜容易出錯(cuò)。
為了解決這些問題，本文將會(huì)介紹一種自動(dòng)生成應(yīng)用程序熱補(bǔ)丁技術(shù)，可以生成應(yīng)用程序和動(dòng)態(tài)鏈接庫(kù)中任意函數(shù)的熱補(bǔ)丁。
二、自動(dòng)生成熱補(bǔ)丁綜述
自動(dòng)生成熱補(bǔ)丁是利用熱補(bǔ)丁生成工具，對(duì)現(xiàn)有的源代碼和補(bǔ)丁文件進(jìn)行處理，自動(dòng)輸出熱補(bǔ)丁的技術(shù)。
我們知道，熱補(bǔ)丁的基本原理是新函數(shù)替換舊函數(shù)，也就是完整的函數(shù)的替換。補(bǔ)丁中可能包含一個(gè)或多個(gè)函數(shù)的修改，這些被修改的函數(shù)都會(huì)被替換掉。上一篇文章介紹過，熱補(bǔ)丁首先把新函數(shù)放入目標(biāo)進(jìn)程的內(nèi)存中，然后修改舊函數(shù)的入口，使之跳轉(zhuǎn)到新函數(shù)。
自動(dòng)生成熱補(bǔ)丁中最主要的部分是自動(dòng)生成新函數(shù)的二進(jìn)制代碼，也稱為是替換代碼。在生成替換代碼時(shí)，主要由以下部分組成：
- 自動(dòng)生成替換代碼。
- 解析替換代碼中使用的符號(hào)。
接下來會(huì)對(duì)以上部分進(jìn)行詳細(xì)的介紹。在介紹之前，必須假設(shè)系統(tǒng)環(huán)境是Linux X86/X86_64，應(yīng)用程序是C語言編譯鏈接的ELF格式可執(zhí)行文件，并且擁有原始程序的源代碼。
三、前后代碼比較生成替換代碼
1. 動(dòng)機(jī)與挑戰(zhàn)
為了生成替換代碼，首先需要知道代碼修復(fù)之后，哪些函數(shù)發(fā)生了改變，然后根據(jù)這些改變，生成替換代碼。使用一種二進(jìn)制比較的方法，通過比較原始程序的二進(jìn)制和修復(fù)后程序的二進(jìn)制，提取出生成替換代碼所需的全部信息。
我們選擇在目標(biāo)文件(object file)的級(jí)別，進(jìn)行前后比較。這樣做的好處是顯而易見的：
- 首先，任何源代碼的改變都會(huì)在目標(biāo)文件的二進(jìn)制代碼中顯示出來。舉個(gè)例子，頭文件.h文件中函數(shù)的參數(shù)如果從int變成了long long，調(diào)用這個(gè)函數(shù)的.c文件由于隱含的類型轉(zhuǎn)換，并不發(fā)生改變。如果在前后代碼對(duì)比發(fā)生在源代碼級(jí)別，甚至預(yù)處理之后，也不能發(fā)現(xiàn)前后.c文件發(fā)生了改變。
- 其次，我們不需要處理語言級(jí)別的特性，比如inline關(guān)鍵字、隱含類型轉(zhuǎn)換、宏等等。這些語言相關(guān)的特性可能隨著語言的發(fā)展會(huì)愈發(fā)復(fù)雜，并且我們也不希望熱補(bǔ)丁局限于某種語言。C語言、C++、匯編都是我們希望可以處理的語言。
- 最后，我們只關(guān)心代碼的二進(jìn)制表達(dá)。在目標(biāo)文件的級(jí)別，二進(jìn)制代碼和代碼組成信息是最完整的，在此進(jìn)行前后代碼比較也是最合理的。
所以，生成替換代碼的思路是，通過比較前后編譯的目標(biāo)文件，提取出差異部分，組成替換代碼。
比較目標(biāo)文件也面臨很多挑戰(zhàn)，主要在于如何從提取出發(fā)生改變的函數(shù)。舉個(gè)例子，由于目標(biāo)文件中默認(rèn)所有的函數(shù)代碼都會(huì)放在.text段，同時(shí).text段中的相對(duì)地址跳轉(zhuǎn)都是相對(duì)于.text段的。也就是說，如果某個(gè)函數(shù)發(fā)生了改變，就算是一行代碼的改變，后面的相對(duì)地址跳轉(zhuǎn)也很可能會(huì)發(fā)生改變(由于符號(hào)位置發(fā)生了改變)。
2. 解決辦法
我們對(duì)目標(biāo)應(yīng)用程序代碼和修復(fù)后代碼分別編譯，逐一比較兩次編譯產(chǎn)生的若干個(gè)目標(biāo)文件。如圖所示：
- 首先，我們編譯原始源代碼，保留所有中間過程中產(chǎn)生的目標(biāo)文件。
- 然后，我們對(duì)原始源代碼打上修復(fù)補(bǔ)丁，再次編譯，構(gòu)建系統(tǒng)(make)一般只會(huì)編譯改變的源文件，保留新生成的目標(biāo)文件。如果沒有構(gòu)建系統(tǒng)或者構(gòu)建系統(tǒng)不如期工作，可以保留所有的目標(biāo)文件。
- 最后，我們比較新生成的目標(biāo)文件和對(duì)應(yīng)的原始代碼編譯出來的目標(biāo)文件，提取出差異部分，組成替換代碼，生成熱補(bǔ)丁。
在比較過程中，我們希望做到可以在函數(shù)級(jí)別上進(jìn)行比較，這樣可以只提取出發(fā)生改變的函數(shù)，并且我們也希望生成的替換代碼是地址無關(guān)的，因?yàn)樘鎿Q代碼可能被加載到任意的內(nèi)存地址。
GCC編譯器提供了-ffunciton-sections和-fdata-section的編譯選項(xiàng)，作用是把函數(shù)和變量放入目標(biāo)文件中獨(dú)立的段(每個(gè)函數(shù)代碼都由獨(dú)立的段來表示)。這樣編譯出的函數(shù)代碼都是地址無關(guān)的、更加通用的二進(jìn)制，可以提取到替換代碼中被加載到內(nèi)存的任意位置運(yùn)行。
在對(duì)前后目標(biāo)文件比較的時(shí)候，我們?cè)贓LF段的級(jí)別進(jìn)行比較(也就是函數(shù)的級(jí)別，因?yàn)楹瘮?shù)都在自己獨(dú)立的段中)。因?yàn)槟繕?biāo)文件是ELF文件，遵守通用的標(biāo)準(zhǔn)。我們可以解析目標(biāo)文件的ELF Header，找到段的開頭(Section Header)，由此找到所有的段。這里我們建議使用一些ELF解析庫(kù)，如libelf、libbfd等。
逐一比較前后目標(biāo)文件中的表示代碼的段，段的內(nèi)容就是函數(shù)的代碼，找到發(fā)生改變的函數(shù)：
- 首先，比較段的大小，如果大小不同，說明函數(shù)發(fā)生了改變。
- 接著，對(duì)段的內(nèi)容進(jìn)行比較，如果某個(gè)字節(jié)不同，而且字節(jié)不屬于重定向的一部分，說明函數(shù)發(fā)生了改變。如果是重定向，檢查重定向計(jì)算之后的指令內(nèi)容是否相同，如果不同，說明函數(shù)發(fā)生了改變(引用了與之前不同的函數(shù)或者變量)。
- 最后，如果段的大小和段的內(nèi)容都沒有改變，說明函數(shù)沒有改變。
需要注意的是，如果補(bǔ)丁中修改的是宏或inline函數(shù)，我們無法做到只提取宏或者inline函數(shù)的差異，因?yàn)楹旰蚷nline函數(shù)會(huì)在編譯過程中被放置在其調(diào)用函數(shù)中，所有調(diào)用函數(shù)都會(huì)改變，所以提取的是所有調(diào)用的函數(shù)。
此時(shí)的替換代碼還不能直接運(yùn)行，因?yàn)樘鎿Q代碼中還可能包含對(duì)其他符號(hào)的引用，我們需要在運(yùn)行替換代碼之前解析這些符號(hào)。
四、替換代碼中的符號(hào)解析
1. 動(dòng)機(jī)與挑戰(zhàn)
我們的替換代碼中只包含改變的函數(shù)代碼，這些函數(shù)中可能會(huì)引用其他沒有改變的符號(hào)(函數(shù)或變量)，所以我們需要根據(jù)符號(hào)引用的規(guī)則(一般為相對(duì)PC地址的相對(duì)地址)，對(duì)引用符號(hào)手動(dòng)重定向。
解析符號(hào)地址面臨的挑戰(zhàn)主要有兩個(gè)：
- 找到運(yùn)行中的程序的符號(hào)所在的地址。
- 如果存在兩個(gè)或者以上相同名字的符號(hào)，找到正確符號(hào)。
2. 解決方法
符號(hào)的地址是在最終鏈接的時(shí)候決定的，如果可執(zhí)行文件是pie(position independent executable)或者是動(dòng)態(tài)鏈接庫(kù)，符號(hào)的地址是一個(gè)相對(duì)地址，是相對(duì)于可執(zhí)行文件或者動(dòng)態(tài)鏈接庫(kù)的代碼段在內(nèi)存中地址的偏移，計(jì)算公式Addr = Base + Offset。其他情況，符號(hào)的地址是一個(gè)絕對(duì)地址，無需計(jì)算。
同樣名稱的符號(hào)在可執(zhí)行文件中可能出現(xiàn)多次(例如兩個(gè)文件中定義了名字相同的static變量)，我們需要從中找到正確的符號(hào)。在鏈接之后，可執(zhí)行文件中的符號(hào)表會(huì)遵守一些固定的規(guī)則，相同源文件中符號(hào)會(huì)一起連續(xù)地記錄，并且在記錄的開頭會(huì)有類型為STT_FILE的符號(hào)，名字為源文件的名字。
舉個(gè)例子，我們?cè)?.c和2.c中同時(shí)定義了static int a，最終可執(zhí)行文件中的符號(hào)表如下所示：
- # readelf -s exe
- …
- Symbol table '.symtab' contains 73 entries:
- …
- 41: 0000000000000000 0 FILE LOCAL DEFAULT ABS 1.c
- 42: 0000000000601038 4 OBJECT LOCAL DEFAULT 25 a
- 43: 0000000000000000 0 FILE LOCAL DEFAULT ABS 2.c
- 44: 000000000060103c 4 OBJECT LOCAL DEFAULT 25 a
因此我們可以通過file+sym規(guī)則找到正確的符號(hào)位置。假設(shè)函數(shù)引用變量a，并且函數(shù)在2.c源文件中，我們首先找到類型為STT_FILE的2.c這個(gè)符號(hào)，然后找到符號(hào)a就可以了。
我們知道符號(hào)的地址后可以對(duì)替換代碼中的引用進(jìn)行手動(dòng)重定向編寫，將編譯時(shí)符號(hào)引用的重定向轉(zhuǎn)換為我們自己在運(yùn)行時(shí)可以識(shí)別的重定向(self relocation)。
- 首先，根據(jù)重定向類型和計(jì)算公式，計(jì)算出引用的符號(hào)，記錄符號(hào)的信息，其中符號(hào)的地址在運(yùn)行時(shí)可以得到。
- 然后，記錄原有的重定向信息，其中重定向的地址在運(yùn)行時(shí)可以得到。
- 最后，在替換代碼(熱補(bǔ)丁)被加載到目標(biāo)程序的內(nèi)存中時(shí)，通過之前記錄的重定向內(nèi)容，修改替換代碼符號(hào)引用位置的內(nèi)容，內(nèi)容由重定向的類型、重定向的地址、符號(hào)的地址計(jì)算得到。
舉個(gè)例子，替換代碼中包含函數(shù)x，函數(shù)x會(huì)在地址P引用正在運(yùn)行的程序中的函數(shù)y。當(dāng)替換代碼被加載到程序的地址空間時(shí)，地址P可以被確定，函數(shù)y的符號(hào)地址S可以被確定，根據(jù)替換代碼中記錄的重定向信息(假設(shè)重定向類型是R_X86_64_PC32，Addend是A)，那么地址P的內(nèi)容需要被修改為S+A-P。這樣當(dāng)函數(shù)x執(zhí)行時(shí)才能引用到函數(shù)y的位置。
五、POC：生成替換代碼、符號(hào)解析
本章節(jié)利用objdump等工具，對(duì)生成替換代碼中的關(guān)鍵步驟進(jìn)行POC驗(yàn)證。
假設(shè)我們有目標(biāo)程序T(修復(fù)后名為T-patched)，包含如下代碼：
- void print(int i)
- {
- while (i) {
- printf("%d ", i--);
- }
- printf("\n");
- }
- void func()
- {
- print(4);
- }
patch文件如下：
- void func()
- {
- - print(4);
- + print(6);
- }
分別將源代碼和修復(fù)后的源代碼編譯，生成T.o和T-patched.o。
通過objdump我們可以發(fā)現(xiàn)func函數(shù)前后發(fā)生了改變，地址0x4的指令不同。(其他函數(shù)不變，省略)。如下所示：
- # objdump -hdr -j .text.func T.o
- …
- Disassembly of section .text.func:
- 0000000000000000 <func>:
- 0: 55 push %rbp
- 1: 48 89 e5 mov %rsp,%rbp
- 4: bf 04 00 00 00 mov $0x4,%edi
- 9: e8 00 00 00 00 callq e <func+0xe>
- a: R_X86_64_PLT32 print-0x4
- e: c9 leaveq
- f: c3 retq
- # objdump -hdr -j .text.func T-patched.o
- …
- Disassembly of section .text.func:
- 0000000000000000 <func>:
- 0: 55 push %rbp
- 1: 48 89 e5 mov %rsp,%rbp
- 4: bf 06 00 00 00 mov $0x6,%edi
- 9: e8 00 00 00 00 callq e <func+0xe>
- a: R_X86_64_PLT32 print-0x4
- e: c9 leaveq
- f: c3 retq
所以提取出T-patched.o中的.text.func段。這就完成了替換代碼的提取。
因?yàn)門-patched.o中的func函數(shù)在0xa的位置上引用了print函數(shù)，我們需要對(duì)print符號(hào)進(jìn)行解析，在替換代碼(熱補(bǔ)丁)被加載到目標(biāo)進(jìn)程內(nèi)存時(shí)，對(duì)0xa-0xd的四個(gè)字節(jié)重定向。
我們記錄下這個(gè)重定向，類型R_X86_64_PLT32，Addend -4，符號(hào)print。
在替換代碼被加載到目標(biāo)進(jìn)程中時(shí)，我們可以確定替換代碼加載的地址。假設(shè)替換代碼中func地址為0x7fa357ed79b0，原程序中print地址為0x7fa358a9979c。那么我們根據(jù)之前記錄的重定向信息進(jìn)行計(jì)算(V = S + A - P)，將func偏移0xa的位置(4字節(jié))寫入0xbc1dde，計(jì)算方法如下：
- 0x7fa358a9979c + (-4) - 0x7fa357ed79ba = 0xbc1dde
這樣重定向之后，替換代碼中的func函數(shù)就能正確引用到原程序中的print函數(shù)。
最后，我們通過GDB觀察T程序打入熱補(bǔ)丁之后的行為：
- (gdb) disas func
- Dump of assembler code for function func:
- 0x00007fa358a997d8 <+0>: movabs $0x7fa357ed79b0,%rax
- 0x00007fa358a997e2 <+10>: jmpq *%rax
- …
以上可以看出原程序的func函數(shù)會(huì)跳轉(zhuǎn)到0x7fa357ed79b0執(zhí)行。
- (gdb) disas 0x7fa357ed79b0
- Dump of assembler code for function func:
- 0x00007fa357ed79b0 <+0>: push %rbp
- 0x00007fa357ed79b1 <+1>: mov %rsp,%rbp
- 0x00007fa357ed79b4 <+4>: mov $0x6,%edi
- 0x00007fa357ed79b9 <+9>: callq 0x7fa358a9979c <print>
- 0x00007fa357ed79be <+14>: leaveq
- 0x00007fa357ed79bf <+15>: retq
- End of assembler dump.
以上可以看出0x7fa357ed79b0是熱補(bǔ)丁中func函數(shù)的入口，也能看出0x00007fa357ed79b9地址的指令中引用了正確的print符號(hào)。
我們通過objdump、gdb驗(yàn)證了替換代碼的靜態(tài)和動(dòng)態(tài)形式，展示了自動(dòng)生成熱補(bǔ)丁的具體細(xì)節(jié)，希望可以借此讓讀者對(duì)此有更清晰的理解。
六、其他注意事項(xiàng)
這種前后目標(biāo)文件比較生成替換代碼的方法，要求我們必須擁有正在運(yùn)行的目標(biāo)程序的源代碼。同時(shí)，在編譯目標(biāo)文件時(shí)強(qiáng)烈建議使用和目標(biāo)程序相同版本的gcc和編譯選項(xiàng)，使用不同的gcc和不同的選項(xiàng)可能會(huì)導(dǎo)致目標(biāo)文件和原始程序的二進(jìn)制不匹配，導(dǎo)致不能生成正確的替換代碼。不正確的替換代碼可能會(huì)導(dǎo)致符號(hào)解析錯(cuò)誤，進(jìn)而是程序崩潰，這里需要特別注意。
七、寫在最后
本文介紹了二進(jìn)制比較方式的自動(dòng)生成熱補(bǔ)丁技術(shù)，相比于上一篇文章中介紹的簡(jiǎn)單熱補(bǔ)丁技術(shù)，優(yōu)勢(shì)在于：
- 通過工具自動(dòng)生成熱補(bǔ)丁，無需手動(dòng)編寫熱補(bǔ)丁，減少了人為出錯(cuò)的可能。
- 可以修復(fù)本地函數(shù)和全局函數(shù)，并且不需要引入函數(shù)的依賴鏈。
- 兼容多種編譯型語言(C語言、C++、匯編等，具體實(shí)現(xiàn)不同，但是思路一致)。
使用這種熱補(bǔ)丁生成技術(shù)，可以解決應(yīng)用程序幾乎所有的安全漏洞。例如最近出現(xiàn)的QEMU CVE-2017-2615(cirrus驅(qū)動(dòng)內(nèi)存越界訪問)，我們對(duì)有bug的函數(shù)都打上了熱補(bǔ)丁，通過替換bug函數(shù)，實(shí)現(xiàn)了在線熱修復(fù)。
生成熱補(bǔ)丁是應(yīng)用程序熱補(bǔ)丁技術(shù)框架中非常關(guān)鍵的一個(gè)組件，本文介紹了一種自動(dòng)生成熱補(bǔ)丁的技術(shù)，但是完整、成熟的熱補(bǔ)丁框架還包含了其他技術(shù)，例如多線程、管理多個(gè)熱補(bǔ)丁、多版本管理、熱補(bǔ)丁與程序之間的一致性檢查等等。
【本文是51CTO專欄機(jī)構(gòu)作者“大U的技術(shù)課堂”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)通過微信公眾號(hào)(ucloud2012)聯(lián)系作者】
