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
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.
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
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
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
Dear diary, on Fri, Apr 15, 2005 at 08:15:37PM CEST, I got a letter
where Allison <[email protected]> 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
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
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
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
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
On 4/15/05, Allison <[email protected]> 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
On 4/15/05, Lee Revell <[email protected]> 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