• 当前位置:首页>>编程开发A>>安全防御>>module injection in 2.6 kernel
  • module injection in 2.6 kernel
  •  

    |=-------------------[ module injection in 2.6 kernel ]-------------------=|
    |=------------------------------------------------------------------------=|
    |=---------------[ CoolQ  <qufuping@ercist.iscas.ac.cn> ]-----------------=|
    |=------------------------------------------------------------------------=|

    0 - 前言
    1 - 2.4 回顾
    2 - 2.6 的变化
        2.1 2.6的.ko文件
        2.2 失效的原因
    3 - 对策
        3.1 修改.rel.gnu.linkonce.this_module
        3.2 例子
    4 - 检测module injection的方法
    5 - 参考
    6 - 代码

    --[ 0 - 前言

    phrack 61期有一篇不错的文章[1],给出了一种感染内核模块的方法,不过是基于2.4
    内核的,该方法在2.6上无效,但是思想还是通用的。通过对2.6内核加载的分析,了解
    两者之间的差异,并最终实现2.6下的module injection。

    --[ 1 - 2.4 回顾

    内核对模块的管理,是通过struct module来实现的,该结构的成员init/cleanup,代表
    加载/卸载模块后需要运行的初始化/收尾函数,它的赋值是通过以下代码实现的:
    module->init = obj_symbol_final_value(f,
                    obj_find_symbol(f, "init_module"));
    module->cleanup = obj_symbol_final_value(f,
                    obj_find_symbol(f, "cleanup_module"));
    可见,insmod需要在.strtab中查找init_module/cleanup_module字符串,并根据索引值
    找到相应的.symtab中的符号,将相应的值赋值给module->init/cleanup。

    因此,如果能把.strtab中别的字符串替换为init_module,那么系统加载的时候,运行的
    就不是原来的init_module函数了。

    --[ 2 - 2.6 的变化

    2.6中的模块子系统被完全重写,如果用[1]中的工具,发现无论怎么修改.strtab,运行
    的始终是原来的init_module。

    --[ 2.1 2.6的.ko文件

    2.6下的模块,扩展名为.ko,而不是2.4下的.o。很多初学者写完模块之后,会使用2.4的
    方法来编译模块
    -----------------------------8 test.c 8--------------------------------------
    #include <linux/init.h>
    #include <linux/kernel.h>
    #include <linux/module.h>

    static int dummy_init(void)
    {
        printk("hello,world.\n");
        return 0;
    }
    static void dummy_exit(void)
    {
        return;
    }

    module_init(dummy_init);
    module_exit(dummy_exit);

    MODULE_LICENSE("GPL")
    ------------------------------8 cut here 8-----------------------------------
    # gcc -c -O2 -DMODULE -D__KERNEL__ -I/usr/src/linux test.c
    # insmod test.o
    No module found in object
    insmod: error inserting 'test.o': -1 Invalid module format

    正确的做法是写一个Makefile,由内核的Kbuild来帮你编译
    -------------------------------8 Makefile 8-----------------------------------
    obj-m := module.o
    KDIR := /lib/modules/$(shell uname -r)/build
    PWD := $(shell pwd)
    default:
        $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
    --------------------------------8 cut here 8----------------------------------
    #make
    make -C /lib/modules/2.6.5-1.358/build SUBDIRS=/test modules
    make[1]: Entering directory `/lib/modules/2.6.5-1.358/build'
      CC [M]  /test/modinject/test.o
      Building modules, stage 2.
      MODPOST
      CC      /test/modinject/test.mod.o
      LD [M]  /test/modinject/test.ko
    make[1]: Leaving directory `/lib/modules/2.6.5-1.358/build'
    #ll
    -rw-r--r--  1 root root   268 Jan  7 08:31 test.c
    -rw-r--r--  1 root root  2483 Jan  8 09:19 test.ko
    -rw-r--r--  1 root root   691 Jan  8 09:19 test.mod.c
    -rw-r--r--  1 root root  1964 Jan  8 09:19 test.mod.o
    -rw-r--r--  1 root root  1064 Jan  8 09:19 test.o

    其实上边的test.o就是用gcc生成的test.o,而test.ko是使用下列命令来生成的
    #ld -m elf_i386 -r -o test.ko test.o test.mod.o

    再来看看test.mod.c,它是由/usr/src/linux/scripts/modpost.c来生成的
    #cat test.mod.c
    #include <linux/module.h>
    #include <linux/vermagic.h>
    #include <linux/compiler.h>

    MODULE_INFO(vermagic, VERMAGIC_STRING);

    #undef unix
    struct module __this_module
    __attribute__((section(".gnu.linkonce.this_module"))) = {
    .name = __stringify(KBUILD_MODNAME),
    .init = init_module,
    #ifdef CONFIG_MODULE_UNLOAD
    .exit = cleanup_module,
    #endif
    };
    static const struct modversion_info ____versions[]
    __attribute_used__
    __attribute__((section("__versions"))) = {
            {        0, "cleanup_module" },
            {        0, "init_module" },
            {        0, "struct_module" },
            {        0, "printk" },
    };
    static const char __module_depends[]
    __attribute_used__
    __attribute__((section(".modinfo"))) =
    "depends=";

    可见,test.mod.o只是产生了几个ELF的节,分别是modinfo, .gun.linkonce.this_module
    (用于重定位,引进了rel.gnu.linkonce.this_module), __versions。而test.ko是test.o
    和test.mod.o合并的结果。

    --[ 2.2 失效的原因

    在2.1给出的test.c中,模块的初始化函数是dummy_init,这是通过module_init
    (dummy_init)来实现的,module_init的作用是把dummy_init作为init_module的alias,这
    个可以查看生成的符号表来验证:
       16: 00000000    14 FUNC    LOCAL  DEFAULT    1 dummy_init
       25: 00000000    14 FUNC    GLOBAL DEFAULT    1 init_module
    看, 符号的st_value都是0,而且除了BIND类型以外,其他的完全一样!

    在2.6的内核源代码中,并没有见到对module->init赋值的操作。问题的关键就是
    test.mod.c中的那个struct module __this_module,这实际上就是内核用来管理的module
    结构。内核装载模块的时候,会将这个节直接复制,并将module的指针指向__this_module
    , 而".init = init_module"将module->init初始化为init_module.

    如果你了解符号的解析过程,你应该很清楚:符号的重定位不需要.strtab的参与

    看一下Elf32_Rel的定义
      typedef struct {
          Elf32_Addr r_offset;
          Elf32_Word r_info;
      } Elf32_Rel;
    和重定位节.rel.gnu.linkonce.this_module
    Relocation section '.rel.gnu.linkonce.this_module' at offset 0x758 contains 2
    entries:
    Offset     Info    Type            Sym.Value  Sym. Name
    00000068  00001901 R_386_32          00000000   init_module
    0000018c  00001801 R_386_32          0000000e   cleanup_modul

  • 上一篇:ipsecpol的规则脚本编写
    下一篇:Superhei 的 tips2