Re: Kernel Rootkits

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: Re: Kernel Rootkits

[Petr Baudis]

Dear diary, on Fri, Apr 15, 2005 at 08:15:37PM CEST, I got a letter
where Allison <fireflyblue@gmail.com> told me that...
> hi,

Hello,

> 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.

I think you are still confused. You are mixing two things:

(1) Getting enough access to the machine to load the rootkit

(2) Loading the rootkit smart enough to slip any detectors

The first part basically involves getting root access to the machine.
This is so broad area that it is out of scope of this mail, I guess, but
innumerable types of vulnerabilities exist, ranging from silly bugs in
programs running as root, to in-kernel bugs which let you elevate your
permissions from a regular user to superuser (root).

The second part is very broad too, I think you would be better off by
doing some research on your own - there are plenty of resources on the
net w.r.t. this. (I hope you are asking only in order to defend
yourself! ;-) Basically, rootkits can range from a set of
custom-tailored binaries like ps and ls which will hide the cracker's
files from you, to linux kernel modules which the attacker will load as
a regular kernel module, but which will then usually hide itself and
then again hide the cracker's files from you, only better. These are
already kind of old-fashioned now, though. E.g. the SucKIT rootkit
installs itself to the kernel by bypassing the traditional kernel module
installing mechanism and writing itself directly to the memory,
overriding certain kernel structures and therefore taking control over
it.

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

once they are in the kernel, they can do anything they want. That's the
point of being in the kernel, after all.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

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

[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

[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

[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, 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