0x07_stmichael

7/30/2019 0x07_stmichael

1/12

[ --- The Bug! Magazine

_____ _ ___ _/__ \ |__ ___ / __\_ _ __ _ / \

/ /\/ '_ \ / _ \ /__\// | | |/ _` |/ // / | | | | __/ / \/ \ |_| | (_| /\_/\/ |_| |_|\___| \_____/\__,_|\__, \/

|___/

[ M . A . G . A . Z . I . N . E ]

[ Numero 0x02 Edicao 0x01 Artigo 0x07 ]

.> 14 de Fevereiro de 2007,

.> The Bug! Magazine < staff [at] thebugmagazine [dot] org >

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+StMichael: Protecting the Linux Kernel Integrity+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

.> Rodrigo Rubira Branco (BSDaemon) < rodrigo [at] kernelhacking [dot] com >

.> < rrbranco [at] br [dot] ibm [dot] com >.> Lucio J. H. Correia < luciojhc [at] br [dot] ibm [dot] com >

[ --- Index

+ 1. Introduction+ 2. Troubles and Solutions+ 2.1. File modification attacks+ 2.2. Self protection+ 2.3. MBR protection+ 2.4. System calls+ 2.5. Installation

+ 2.6. Demo attacks+ 3. StMichael Internals+ 4. Issues and Incompatibilities+ 4.1. PCMCIA-CS+ 4.2. Grate security+ 4.3. AC kernels+ 5. Conclusion+ 6. References

[ --- 1. Introduction

Linux operating system is not secure, by default. There have been many

approaches to improve its security features. Most of them don't protect thekernel mode itself, so a malicious program, acting like win32 worms, can injectcode into the kernel to change the system features.

This work intends to show StMichael [1] project, which aims to provide thiskind of protection at kernel-level, performing lots of integrity checks in ker-nel internal structures and defeating the different kinds of attacks againstit. StMichael [1] is a LKM [2] that provides this protection by monitoringvarious portions of the kernel, and optionally the entire kernel text itself,for modifications that may indicate the presence of a malicious kernel module.


2/12

If rootkit-like activity is detected, StMichael will attempt to recover thekernel's integrity by rolling back the changes made to a previously known-goodstate.

The following is a brief list of the capabilities of StMichael kernel module:

- Can generate and check MD5 and, optionally, SHA1 checksum of several kerneldata structures, such as the system call table, and filesystem call outstructures;

- Can checksum (MD5 only) the base kernel, and detect modifications to thekernel text such as would occur during a silvo-type attack;

- Can backup a copy of the kernel, storing it in an encrypted form, for resto-ring later if a catastrophic kernel compromise is detected;

- Can detect the presence of simplistic kernel rootkits upon loading;

- Can modify the Linux kernel to protect immutable files from having theirimmutable attribute removed;

- Can disable write-access to kernel memory through the /dev/{k}mem device;- Can conceal StMichael module and its symbols;

- Can monitor kernel modules being loaded and unloaded to detect attempts toconceal the module and its symbols and attempt to "reveal" the hidden module.

[ --- 2. Troubles and Solutions

This section presents some common issues related to rootkit attacks, andtheir respective solutions as implemented by StMichael kernel module.

[ --- 2.1. File modification attacks

Linux has the chattr tool to change the attribute of a file. When an "chattr

+i" is issued on a file, that file can not be changed or removed anymore, be-cause it becomes immutable. But root user can simply do "chattr -i" in thisfile, and then remove it.

StMichael [1] implements a concept called "really immutable". This feature doesnot permit an immutable file to be mutable again. The following steps show howStMichael does that:

- it hooks the VFS ioctl call:

current->files->fd[fd]->f_op->ioctl = (void *) sm_ext2_ioctl;

- it tests the call flags:

if (inode->u.ext2_i.i_flags & S_IMMUTABLE)

- and sets it again:

flags |= S_IMMUTABLE;

- then returns the original call:

return orig_ext2_ioctl (inode, filp, cmd, arg);


3/12

Lots of files need to be write-protected. A list of files recommended to be setimmutable when using StMichael is included in StMichael's Docs/ subdir.This list is just a sample for a generic system. It can be necessary to add,remove, or change this list to fit it to a specific system.The goal of this list is to set immutable every file in a prior moment to theactual loading of StMichael LKM. This is done by simply run: "chattr +ifilename"

The file list includes:

- the kernel images listed in /etc/lilo.conf. If using grub, setting asimmutable all files in /boot/grub directory will prevent the attacksagainst grub presented by [3].

/boot/*vmlinuz*/boot/*System.map*/vmlinuz*/System.map*

- the configuration files that affect the loading of the kernel:

/etc/lilo.conf

- the binary programs that are run by the kernel, prior to and during theload of StMichael:

/sbin/insmod/sbin/init

- the configuration files used by these programs:

/etc/inittab

- the libraries the programs use:

/lib/libc.*/lib/libc-*/lib/ld-*/lib/i[3456]86/libc*

- the configuration files for the linker:

/etc/ld.so.conf

- the creation, if necessary, and definiton as immutable is done by doing:

touch /etc/ld.so.preloadchattr +i /etc/ld.so.preload

The preload configuration file may be used to introduce malicious librariesinto the preload sequence of dynamically linked programs. This is bad.

- all modules located at:

/lib/modules/`uname -r`

[ --- 2.2. Self protection


4/12

After loaded, StMichael [1] removes itself from the modules list, and thusdestructs itself with the kernel locked:

-- snip --

// This function will self destruct in 5// miliseconds...

unsigned long filler = 0x00000000;unsigned long *p;

for (p = (unsigned long *) &m; p < (unsigned long *) &filler; p++) {*p = filler;

}

sjp_l_bzero((void *) (THIS_MODULE), sizeof(struct module));

-- snip --

It also uses encrypted messages to avoid signature detection of StMichael'scode:

-- snip --

char *sm_message_strings[] = {"Failed to Initilize.\n","Evasion of Filesystem Checks Detected.\n","Covert Kernel Module Detected. Revealed.\n",...

}

-- snip --

And then it uses encryption/decryption functions with random keys. These keysare generated during the load of the module, so no one, including the admin-istrator of the system, knows the key:

-- snip --

char *sjp_l_decrypt_data (char *p, long len)

void sjp_l_crypt_data (char *p, long size)

-- snip --

Of course it is necessary to implement all the string functions, like'void sjp_l_free( void * memory, unsigned long size)', which calls do_munmapdirectly, not relying in really easily hooked functions.

Also 'void * sjp_l_malloc(unsigned long size)', which calls do_mmap directly,must be implemented. Many others have been implemented and are referenced inStMichael string_util.c file.

[ --- 2.3. MBR Protection

As spooted at Phrack 63 [3], an attacker can inject code onto the MBR of thesystem (by attacking grub itself) to load an arbitrary backdoor into the kernelcode, before StMichael or the system [1] has been loaded.


5/12

To avoid this kind of attack, StMichael provides the MBR protection mechanism.It's just a simple function, 'mbr_read', that reads the MBR contents and saveit in a buffer, to be hashed and checked.

[ --- 2.4. System calls

StMichael [1] also hooks some system calls like create_module, delete_moduleand init_module. These are the reasons:

- create module is hooked to put kmem as read-write before registering themodule and add the new module into the StMichael list;

- init module is hooked to check the system integrity after loading themodule;

- delete module is hooked to check the integrity after module has beenremoved and unregistered with StMichael. Also checks if the deletedmodule is not a try to delete StMichael itself;

- exit is hooked to check the integrity of the system after a process exits.

[ --- 2.5. Installation

The StMichael [1] kernel module needs to be configured prior to its build-ing. A "configure" script is included to generate its configuration. Afterrunning "./configure", new configuration is stored in a "Makefile.in" file.This file is called by Makefile to set the definitions that control the compi-lation process. Once the Makefile.in file has been generated, running "make"does the build of the kernel module.

The module can be tested by running "insmod ./StMichael.o". This loads theStMichael kernel module with the configuration earlier defined. If everythingappears to work properly, it is recommended to play with some of the demoattack scripts.

When deploying StMichael to a system, the module must be loaded at the firstpossible moment. This can be done by loading the module prior to entering theinitial runlevel. This is accomplished by adding the following line to'/etc/inittab', assuming the compiled StMichael.o file has been copied to'/lib/modules'. This line should be added before rc.sysinit script is called.After loaded, StMichael outputs events to the kernel logging facility.

sm:35:once:/sbin/insmod/lib/modules/StMichael.o

An important question when talking about a security module is how can it besecurely loaded at boot time?

If the attacker tries to remove the module, perhaps rebooting the system, howresistant will it be? If the attacker uses some way to insert a backdoor in theearly stage of the booting, will the system enforce the security?

The way StMichael works requires it to be loaded earlier in the boot process,in order to protect the system from hostile acts. The earlier in the boot pro-cess it loads, the better.

In some situations, particularly when '/bin/init' can be trojaned, it is neces-sary to load the modules prior to init spawning. Within Linux, the only way to


6/12

load a kernel module prior to init spawning is through initrd [11] (initialramdisk).

When loaded through initrd, StMichael can easily detect malicious activity doneby the programs which load before it. Additionally, on systems already compro-mised by a kernel level rootkit, a pre-built initrd can be loaded through lilo(or grub) interface. By doing this, StMichael is loaded before the kernelrootkit and is able to detect it, speeding up the recovery from this kind ofattack. The following items describe the steps to load StMichael through initrdare.

1) Configure and compile the modules with the symbol extraction;

./configure && make thing

2) Copy the module StMichael to operating system's/lib/modules/`uname -r`/kernel directory;

3) Run "depmod -a";

4) Change directory to /boot directory;

5) Run "mkinitrd with StMichael lkm initrd-

sm.img `uname -r`";

6) Modify lilo or grub to use initrd, as in the following examples; LiloExample (lilo.conf):

prompttimeout=50default=linux-with-stmichaelboot=/dev/hdamap=/boot/mapinstall=/boot/boot.bmessage=/boot/messagelinear

image=/boot/2.4.19-pre1/vmlinuzlabel=linux-without-stmichaelread-onlyroot=/dev/hda6append="hdc=ide-scsi"image=/boot/2.4.19-pre1/vmlinuzlabel=linux-with-stmichaelread-onlyroot=/dev/hda6append="hdc=ide-scsi"initrd=/boot/2.4.19-pre1/initrd-sm.img

Grub Example (menu.lst):

default 0timeout 50color cyan/blue white/bluetitle StMichael Modified Kernelroot (hd0,4)kernel /boot/vmlinuz-2.4.31 \root=/dev/hda5 roinitrd /boot/initrd.img-2.4.31


7/12

savedefaultboottitle Original Distro Kernelroot (hd0,4)kernel /boot/vmlinuz-2.4.31 \root=/dev/hda5 rosavedefaultboot

7) Reboot.

[ --- 2.6. Demo attacks

The DEMO ATTACKS directory contains interesting attack situations thattries to defeat StMichael [1] protections. All these attacks have been issuedand solved by a StMichael feature. The next subsections analyse them.

1) printk exploit.c

This exploit tries to modify printk to discover and spot StMichael by runningarbitrary code. That's why StMichael implements 'int sjp_l_printf(const char*fmt,...)'.Indeed, this function relies on sys write, but sys call table is protected by

the integrity code. printk address is also protected, but the attack uses codeinjection, not address modification.

2) test attack.c:

This attack uses five different approaches:

- Hide the module;

- Execute code during the loading of the module;

- Change the sys call table;

- Change an specific function address;

- Overwrite the function called by delete module system call with aninvalid address '0xdeadbeef '

StMichael has anti-lkm concealment, that detects the modules trying to hide it.It has interesting stuff that tries to discover modules changing an address notcontained in itself and some other important implementations. The attack toStMichael itself causes a kernel panic, not a system compromise.

3) timer exploit.c:

This exploit is really interesting. Some systems rely on the system timer so itexecutes in a pre-defined ticks of time. This attack tries to define a backdoorthat uses this to remove the backdoor when the system will check kernel inte-grity, and then put it back after the check. StMichael uses a randomly timer toprevent this kind of attack.

[ --- 3. StMichael Internals


8/12

This section presents some questions about StMichael internals. These questionswere compiled by Yan Harry. Following each of them are the respective answers:

1) In the following codes about sys call table in StJude lkm.c file, why theaddress of sys_call_table is between &loops_per_jiffy and &boot_cpu_data?

-- snip --

sys_call_table = NULL;for (ptr = (unsigned long) & loops_per_jiffy;

ptr < (unsigned long) &boot_cpu_data;ptr += sizeof(void *))

{

unsigned long *p;p = (unsigned long *) ptr;if (p[1] == (unsigned long) sys_exit){

sys_call_table = (void **) p;break;

}

}

-- snip --

Answer:

a) Loops per jiffy and boot cpu data are exported;

b) The address of sys call table is between loops_per_jiffy andboot_cpu_data. This can be seen in System.map file;

c) The second syscall into sys_call_table is sys_exit.

For i386 platform, the definitions are as follows:

- sys_call_table is defined in 'arch/i386/kernel/entry.s';

- loops_per_jiffy is defined in 'init/main.c' file:

unsigned long loops_per_jiffy =(1


9/12

integrity of many parts of the kernel: if the sys_call_table[] pointerspoint to a kernel text area, the integrity of the functions called itself,among others.

3) In the following codes about sj_s_text and sj_e_text in init module() func-tion, sj_s text is the start of kernel text and PAGE_OFFSET is OXC0000000 oni386 platform in Linux kernel;sj_e_text is the end of kernel text. Why were sj_s_text and sj_e_text compu-ted that way?

(1) sj_s_text = (void*)(PAGE_OFFSET | 0x00100000);(2) for (m=*eml; m->next; m=m->next);(3) for (s=m->syms; s->name; s++);(4) sj_e_text = (void *) s;

Answer: At line 1 sj_s_text is pointed to the start of kernel text.PAGE_OFFSET -- 0x00100000 returns the init of the kernel text:PAGE_OFFSET(0XC0000000) - THE START OF VIRTUAL KERNEL SPACE. Allnormal kernel code in vmlinuz is compiled with the base address atPAGE OFFSET + 1MiB, the kernel is actually loaded beginning at thefirst megabyte (0x00100000) of memory. The first megabyte is used bysome devices for communication with BIOS and is skipped. Lines 2 and3 will loop through the modules structures until the end of them and

the symbols/names. At line 4 sj_e_text is pointed to the end of ker-nel text, because a sys call table address not being betweensj_s_text and sj_e_text was certainly modified.Both sj_s_text and sj_e_text are used in the macro IS_IN_KERNEL_TEXTas that macro checks if the address of the syscalls are into thecorrect place without need to hash or check each address (merely anapproach used at the load).

4) It has been noticed sys_call_table symbol is used to replace system calls,but sys_call_table isn't exported in Linux 2.6.*, so how system calls inLinux 2.6.* can be modified?

Answer: The method is in StJude lkm.c file.

Refer to question 1.

5) /dev/kmem was disabled to be part of StMichael. This can possibly affect thefollowing normal function [8]:

a) Some boot loaders, such as lilo, need to access /dev/mem or /dev/kmemfor getting BIOS data;

b) klogd uses such access, probably for decoding oops messages (it canprobably operate fine without it for some loss of functionality);

c) vmware uses such access (and lots of other invasive access types tokernel memory);

d) many xdm type programs read kernel memory as a source of randomness.This is bad because kernel memory is not random and it may leak someinformation from the kernel. xdm in Fedora should be fixed to use/dev/random;

e) X server needs such access if it's accessing the hardware directly.When using fbdev it should not need such access.

Answer: No one needs to write into /dev/kmem. Applications 1-4 are just


10/12

getting info from /dev/kmem using read operation. There are prob-lems with old X servers and PaX [5] patchs because /dev/kmemwrite needed... It doesn't exist anymore.

6) It was found out that both StJude [1] and StMichael work only with Linux2.2.* and 2.4.*. Is there any plan to make it work for Linux 2.6.*?

Answer: Yes. The work on that has started, as can be seen in [6]. Next ver-sion will be for 2.6 kernel. The plan is to maintain a 2.2/2.4 ver-sion and another for 2.6 (it's not desired to keep backward compati-bilities because 2.6 kernel has changed a lot of its module constru-ction).

7) What are the difficulties in the port to Linux 2.6.*?

Answer: Time is the major difficult. Version 2.6 has changed the moduleconstruction and a lot of structures. A lot of others has beenadded. It's necessary to check LSM integrity too - it already existsin the draft coded for [6].

8) Is there any more detailed document about StJude and StMichael projectsavailable, with exception of documents fromhttp://sourceforge.net/projects/stjude?

Answer: No. The documentation provided explains all the ideas behind themodules and the model. The code itself is documented to explain thecode structure and technical details of the project. "On IntrusionResilience" [7] is the original idea and the initial concepts thatjustify the creation of StMichael. This document intends to be anuseful documentation.

9) Why are there many functions replacing standard system functions in StJudestring util.c? For example, sjp_l_strlen replaces strlen.

Answer: Because the original strlen is exported by the kernel. So, a crackercan hook that and thus break StJude checks. It's like the comment inthe printf function: "This is a more secure replacement for printk.

It's a local function to this module and its address isn't exportedto the kernel, so it isn't so easy to modify as printk".

[ --- 4. Issues and Incompatibilities

This section presents known issues and incompatibilities between StMichael[1]and other kernel patches and modules.

[ --- 4.1. PCMCIA-CS

There have been some issues with PCMCIA-CS [10] and StMichael. It seems that

when PCMCIA-CS modules are loaded into the kernel, the system call table ismodified. These are legitimate modifications. Similarly, when PCMCIA-CS modules(including autoclean) are removed from the kernel, these system calls are remo-ved.

In the first case, the fact that StMichael flags these as rootkit activity andreverses the changes has little effect other than disabling the PCMCIA subsys-tem.

In the latter case, the effects can be catastrophic. If calls are made to the


11/12

system call, the entry that is in the system call table points to unallocatedportions of data. The effects of calling this can range from oopsing the systemto opening a potential avenue for malicious code to be executed.

To exploit this, malicious code has to be overlayed on top of the exact placewhere the original PCMCIA functions were. This is considered from difficult tonon-trivial, but possible.

It is not recommended, at this time, to use StMichael on a laptop that loadskernel modules for PCMCIA support, or any other service that installs or remo-ves new system calls.

[ --- 4.2. Grate security

If loaded on a system that is using a grate security kernel patch, likeGrSecurity [4], StMichael may oops. This oops occurs on kernel loading. At thistime, the cause of the problem is unknown.

[ --- 4.3. AC kernels

Alan Cox kernel series seem to have made modifications to the 2.4.XX kernelmemory manager. These modifications may conflict with StMichael and cause its

compilation to fail.

StMichael 0.10 has been modified to work with the 2.4.19-pre3-ac3 kernel patch.The compile time option -DACKERNEL turns on this support.

Depending on the changes in future AC kernels, other issues may crop up.

[ --- 5. Conclusion

It was presented StMichael [1], a kernel-level security tool for Linux ope-rating system. StMichael's internals were showed in detail, since its installa-tion and use process to developer questions about its source code.

So this document is considered to be unique in the literature.

An interesting feature of StMichael is its self-protection mechanism. Severalother tools that aim to protect every kind of systems are not able to protectthemselves. Other intersting features are MBR protection and demo attack appli-cations.

Due to its consistent security model, StMichael can be applied to systems thatrequire a strong security level, since Linux kernel 2.4 series are not animpeachment.StMichael isn't recommended to be run in production systems running under Linuxkernel 2.6 series. It's expected that future releases of StMichael be ready tothis.

[ --- 6. References

[1] Lawless, Timothy; Branco, Rodrigo R. StJude and StMichaelProjects.Reference: http://www.sf.net/projects/stjude.Last Access: 08/16/2006.

[2] Salzman, Peter Jay; Burian, Michael; Branco, Rodrigo R.


12/12

The Linux Kernel Module Programming Guide.Reference: http://sourceforge.net/projects/lkmpg.Last Access: 08/16/2006.

[3] CoolQ. Hacking Grub for fun and profit.Reference: http://www.ouah.org/p63-0x0a Hacking Grub.txt.Last Access: 08/16/2006.

[4] Spengler, Brad. GrSecurity Kernel Patch. Reference:http://www.grsecurity.net. Last Access: 08/16/2006.

[5] PaX Team. PaX Security Kernel Patch. Reference:http://pax.grsecurity.net. Last Access: 08/16/2006.

[6] Branco, Rodrigo R. KIDS - Kernel Intrusion Detection System.Draft. Defcon 2006, Las Vegas, USA.

[7] Lawless, Timothy. On Intrusion Resilience.Reference: http://superb-west.dl.sourceforge.net/sourceforge/stjude/OIR.pdfLast Access: 08/16/2006.

[8] Coker, Russel. Re: preventing /dev/kmem and /dev/mem writes? DebianSecurity Mailing List.Reference: http://lists.debian.org/debian-security/2004/07/msg00186.html.

[9] sd; devick. Linux on-the-fly kernel patching without LKM.Phrack 58 Article 0x07.

[10] The Linux pcmcia-cs Package. Reference: http://pcmcia-cs.sourceforge.net/

[11] Almesberger, Werner; Lermen, Hans. Using the initial RAM disk (intird).Linux Kernel Source Code: Documentation/initrd.txt.Reference: www.kernel.orgLast access: 18/08/2006

0x07_stmichael

Documents