CS38, Security and Privacy, Spring 2005

Patching the kernel of a running system is the most efficient method of rootkitting (i.e. hiding the attacker's presence on the system and any use made of systems resources for illicit purposes, which includes files, processes and network connections).

  • Linux rootkit LKMs HOWTO, pragmatic/THC
     [local LKM_HACKING.html]
    An old but detailed LKM rootkit tutorial

    See also past lecture notes for references to kernel system call hijacking, especially Phrack 58:6 Phrack 59:5 [local Phrack mirror].

    SLIDES from the class

    I suggest the cross-referenced Linux code project http://lxr.linux.no for looking at kernel code. Most likely, you will want to start with a particular function or variable, i.e. a "symbol" in linking terms, so you will start with "Identifier search". "Freetext search" is useful when you don't know the exact symbol name. Symbol names in LXR are links to the place where the symbol is defined. Sometimes the definition is detected incorrectly (kernel macros are quite complex, and LXR only does regexp matching), then "Freetext search" also helps.

    There is no single "good starting point" for looking at kernel code, but Phrack articles name the most sensitive pieces security-wise, and http://kernelnewbies.org/ will help.

    a medley of LKM rootkits

  • Runtime kernel kmem patching, Silvio Cesare
    http://vx.netlux.org/lib/vsc07.html  [local vsc07.html]
    The Linux kernel is itself an ELF file and obeys the standard linking conventions (this fact can be. It depends on them for the ability to load modules into the running kernel (the lack of this ability for earlier Windows made necessary the continual reboots after installing software or hardware). With write access to memory, this mechanism can be manipulated, just as any other userland program's address space (compare next link). See also Phrack 58:7 for futher development of these ideas.

  • Runtime process infection, Anonymous
    http://www.phrack.org/show.php?p=59&a=8
    Modifying (infecting) one user process from another. In principle, this is not different from what one can do with a good debugger, and indeed the author describes elements of the normal OS support for debugging, but he (she?) also points out the data structures to be patched. Compare this with the _kernel_ modification (above links).

  • Making System Calls from Kernel Space, Alessandro Rubini
    http://www.linux.it/~rubini/docs/ksys/ksys.html  [local ksys.tar.gz]  [local khttpd.tar.gz]
    This article describes the practicalities of implementing services in the Linux kernel. The application considered in this paper is an fast in-kernel HTTP server, but the same technique is applied by in-kernel backdoors. Incidentally, the system call diagram from the slides is from this article. More details on in-kernel programming in the next paper: http://www.linux.it/~rubini/docs/khttpd/khttpd.html

  • Kfence.c, ins1der
    http://packetstorm.linuxsecurity.com/linux/security/Kfence.c  [local Kfence.c]
    If you really want to get your hands dirty, here is a hacker's ad-hoc kernel strengthening patch. It is installed by patching the live kernel though /dev/kmem in the system call dispatcher procedure. It finds the location of the syscall table by looking up the int80 handler in the Interrupt Descriptor Table (IDT) and inserts its own ad-hoc checks in front of the kernel's entry.S code, written in assembly. For more info on using the IDT look at Phrack 59:4 and the follow-up Phrack 59:10.

    Back to Dartmouth CS Home Page     Sergey Bratus