Kernel Rootkits

Kernel Rootkits

[Allison]

Hi,

I was curious about how kernel rootkits become a part of the kernel ?
One way I guess is by inserting a kernel module.  And rootkits also
manage to hide themselves from rootkit detectors.

few questions:
1. Are there any other ways by which rootkits become part of the kernel ?

2. If modules can access only exported symbols, how is it that kernel
rootkits manage to get hold of other information from the kernel ? For
ex, the process table.

I am not familiar with the /dev/kmem interface. Does this interface
let any kernel module read any symbol (even non-exported) from the
kernel ?

3. If I want to hide a function which is part of the kernel from
kernel modules, is this possible ideally ?

thanks,
Allison

Re: Kernel Rootkits

[Richard B. Johnson]

On Fri, 15 Apr 2005, Allison wrote:

> Hi,
>
> I was curious about how kernel rootkits become a part of the kernel ?
> One way I guess is by inserting a kernel module.  And rootkits also
> manage to hide themselves from rootkit detectors.
>

I'm not sure there really are any "kernel" rootkits. You need to be
root to install a module and you need to be root to replace a kernel
with a new (possibly altered) one. If you are root, you don't
need an exploit.

> few questions:
> 1. Are there any other ways by which rootkits become part of the kernel ?
>

Anybody with knowledge of kernel internals could write some code
and put it into the kernel. The code could do anything the kernel
can do. That kernel could replace an existing one.

You can make your own development system where you know the root
password. You can make a new kernel with whatever Trojans you
want, create a bootable floppy (or Flash RAM disk), then reboot
the target machine with that boot device. The new kernel and its
startup code that you develop could mount the target-machine
root file-system and replace its kernel with yours.

A subsequent reboot brings up the target machine as though
normal. Then, whenever you are logged onto the target machine,
even as a normal user, you could call your new kernel function
with a simple 'C' program.

> 2. If modules can access only exported symbols, how is it that kernel
> rootkits manage to get hold of other information from the kernel ? For
> ex, the process table.
>

Modules can access any symbol that is in /boot/System.map if it's
the correct System.map for the current kernel version.

> I am not familiar with the /dev/kmem interface. Does this interface
> let any kernel module read any symbol (even non-exported) from the
> kernel ?
>

That doesn't contain symbols. It's a binary image of the executing
kernel. You need to be root to read the contents.

> 3. If I want to hide a function which is part of the kernel from
> kernel modules, is this possible ideally ?

It is possible to obfuscate the function by indirection. As a
practical matter, a module can be built which can access anything
in the kernel address-space. Exporting symbols isn't necessary
at all. It's just a protocol.

>
> thanks,
> Allison
> -


Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Kernel Rootkits

[Malita, Florin]

On Fri, 2005-04-15 at 13:16 -0400, Richard B. Johnson wrote:
> I'm not sure there really are any "kernel" rootkits. You need to be 
> root to install a module and you need to be root to replace a kernel 
> with a new (possibly altered) one. If you are root, you don't 
> need an exploit.

rootkit != exploit

The exploit is used to gain root privileges while the rootkit is used
after that to install & hide backdoors, sniffers, keyloggers etc.

http://en.wikipedia.org/wiki/Rootkit

Re: Kernel Rootkits

[Lee Revell]

On Fri, 2005-04-15 at 13:33 -0400, Malita, Florin wrote:
> On Fri, 2005-04-15 at 13:16 -0400, Richard B. Johnson wrote:
> > I'm not sure there really are any "kernel" rootkits. You need to be 
> > root to install a module and you need to be root to replace a kernel 
> > with a new (possibly altered) one. If you are root, you don't 
> > need an exploit.
> 
> rootkit != exploit
> 
> The exploit is used to gain root privileges while the rootkit is used
> after that to install & hide backdoors, sniffers, keyloggers etc.
> 
> http://en.wikipedia.org/wiki/Rootkit
> 

"Rootkit" is sometimes used to refer to the all-in-one bundle, that
contains the exploit and the tools the attacker installs once they are
in.

OT: the dumbest rootkit I ever came across came from someone who cracked
one of our nameservers via an openssh hole.  They were careful to
replace netstat, ps, etc but apparently didn't know about lsof, which
was the first thing I tried of course.  Then they hid the old binaries
in a subdirectory of /dev (because no one would ever look there).
Thanks to the "l33t skillz" of the author, I didn't even have to wipe
the machine to recover it.

Lee

Re: Kernel Rootkits

[Allison]

hi,

I got the terminology mixed up. I guess what I really want to know is,
what are the different types of exploits by which rootkits
(specifically the ones that modify the kernel) can get installed on
your system.(other than buffer overflow and somebody stealing the root
password)

I know that SucKIT is a rootkit that gets loaded as a kernel module
and adds new system calls. Some other rootkits change machine
instructions in several kernel functions.

Once these are loaded into the kernel, is there no way the kernel
functions can be protected ?

thanks,
Allison

Re: Kernel Rootkits

[Daniel Souza]

In fact, LKM's are not the unique way to make code run in kernel. In
fact, we can install a kernel rootkit even when LKM support is
disabled. For example, by patching the kernel memory, you can modify
the behavior of kernel on-the-fly without restart the machine, just
inserting code in the right memory addresses (generally writing to
/dev/mem or /dev/kmem or using another methods like set a userspace
memory limit to KERNEL_DS and write to addressable kernel memory. You
can also insert code into existing kernel modules (for example, your
NIC driver) to be executed when the kernel shuts up). LKMs have the
advantage of relocation (i.e., the kernel's internal function adresses
are "readressed" to fit the existent function addresses and a call to
printk will point to the start of printk function at kernel memory).
Inject executable code at kernel memory can be done without LKM
support, but also, is not automatically relocated. There are some
tricks to make injected code work fine like use only non-global
variables and allocate needed memory space in the stack, or made a
hard relocation of binary code to be injected before the injection,
etc.

Google for things like "suckit". phrack is also a good start.

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil

Re: Kernel Rootkits

[Lee Revell]

On Fri, 2005-04-15 at 18:15 +0000, Allison wrote:
> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?

No.  If the attacker can load arbitrary code into the kernel, game over.
Think about it.

Lee

Re: Kernel Rootkits

[Lennart Sorensen]

On Fri, Apr 15, 2005 at 06:15:37PM +0000, Allison wrote:
> I got the terminology mixed up. I guess what I really want to know is,
> what are the different types of exploits by which rootkits
> (specifically the ones that modify the kernel) can get installed on
> your system.(other than buffer overflow and somebody stealing the root
> password)
> 
> I know that SucKIT is a rootkit that gets loaded as a kernel module
> and adds new system calls. Some other rootkits change machine
> instructions in several kernel functions.
> 
> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?

Well you could build a monilithic kernel with module loading turned off
entirely, but that doesn't prevent replacing libc which most programs
use to make those system calls.  Could make the filesystem readonly,
that would prevent writing a module to load into the kernel, and
replacing libc as long as you make it imposible to remount the
filesystem at all.

Len Sorensen

Re: Kernel Rootkits

[Daniel Souza]

PS: suckit is not loaded as a kernel module. it uses interrupt gates
to allocate kernel memory and install itself in that memory block,
patching some syscalls and doing other stuffs.

A way to "protect" system calls is, after boot a trusted kernel image,
take a MD5 of the syscalls functions implementations (the opcodes that
are part of sys_read for example) and store it in a secure place. To
verify the integrity of system calls, we can check the current
checksum with the stored ones. Of course, there are other ways to trap
syscalls and hook the system instead of just replace the syscall table
or add JMPs to the start of functions implementation. In that way,
everytime somebody will find another way to trick the system and
bypass this 'protection'.

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil

Re: Kernel Rootkits

[Allison]

Isn't the kernel code segment marked read-only ? How can the module
write into the function text in the kernel ? Shouldn't this cause some
kind of protection fault ?

thanks,
Allison

Lee Revell wrote:
> On Fri, 2005-04-15 at 18:15 +0000, Allison wrote:
> > Once these are loaded into the kernel, is there no way the kernel
> > functions can be protected ?
> 
> No.  If the attacker can load arbitrary code into the kernel, game over.
> Think about it.
> 
> Lee
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Rootkits

[Andre Tomt]

Lennart Sorensen wrote:
> Well you could build a monilithic kernel with module loading turned off
> entirely, but that doesn't prevent replacing libc which most programs
> use to make those system calls.

As pointed out elsewhere, modules is not the only way to load kernel 
code live. Modules is just a cleaner interface for it. Rootkits capable 
of loading their kernel code without involving the module system has 
existed for ages.

> Could make the filesystem readonly,
> that would prevent writing a module to load into the kernel, and
> replacing libc as long as you make it imposible to remount the
> filesystem at all.

Don't hold your breath - code can be inserted without involving actual 
files. It just makes things less persistent.

-- 
Cheers,
André Tomt

Re: Kernel Rootkits

[Lee Revell]

On Fri, 2005-04-15 at 11:40 -0700, Daniel Souza wrote:
> A way to "protect" system calls is, after boot a trusted kernel image,
> take a MD5 of the syscalls functions implementations (the opcodes that
> are part of sys_read for example) and store it in a secure place.

That's the problem, once the kernel is compromised there's no such thing
as a secure place.  Solving this problem requires things like "trusted
computing" aka hardware support.

Lee

Re: Kernel Rootkits

[Daniel Souza]

On 4/15/05, Allison <fireflyblue@gmail.com> wrote:
> Isn't the kernel code segment marked read-only ? How can the module
> write into the function text in the kernel ? Shouldn't this cause some
> kind of protection fault ?

The kernel code segment is totally unacessible to userspace programs,
and to kernel itself, is marked read-write. A module runs at kernel
level, so, it has +rw to kernel memory. Each process has a task
structure that defines the top of memory that the user process can
access (current->fs). In normal processes, this is 0xbfffff (the last
adressable memory in user mode). After that, 0xc00000, starts the
kernel code. If, by using any method, a user process receives a
(current->fs = KERNEL_DS), it will be able to fully access the kernel
memory. As mentioned, this is unsual.

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil

Re: Kernel Rootkits

[Daniel Souza]

On 4/15/05, Lee Revell <rlrevell@joe-job.com> wrote:
> On Fri, 2005-04-15 at 11:40 -0700, Daniel Souza wrote:
> > A way to "protect" system calls is, after boot a trusted kernel image,
> > take a MD5 of the syscalls functions implementations (the opcodes that
> > are part of sys_read for example) and store it in a secure place.
>
> That's the problem, once the kernel is compromised there's no such thing
> as a secure place.  Solving this problem requires things like "trusted
> computing" aka hardware support.

yes, hardware support like a floppy disk or a memory key with the
read-only switch turned on after a sucessful boot storing the
hashes... paranoia that works  =) Or just print them, and when in
doubt if your kernel is patched, take another checksum of system calls
and compare to paper... =)

Ok, kidding apart, there's no way to safely protect the system against
memory patching. Maybe, some hardware lock that will keep a "code
segment block" of kernel memory as read-only and a separated segment
for data (as read-write), and after the boot and kernel load, this
lock is activated by a asm call or something like that. This stills
not functional, to not mention impossible. You can implement ways to
make kernel memory patching harder, like avoid any mechanism that can
give direct access to memory like /dev/mem, or /dev/kmem (or patch
them to avoid access to specific areas, because some applications like
Xorg uses direct memory access with that mechanisms to do they duty.)
In fact, avoid any mechanism that can be used by userspace processes
to read/write memory data above 0xc00000. This will also not avoid
kernelspace exploitation from programming bugs (like recent (?) VMA
problems, and ancient ptrace bugs that could lead to privilege
elevation). It's just a mechanism to help securing a system.

Or just try grsec =)

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil