Re: Kernel Rootkits

[Daniel Souza <thehazard@gmail.com>]

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