lkml.org 
[lkml]   [2009]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [kernel] Question about 2.6.28 kernel
From
Date
On Tue, 2009-02-03 at 17:36 +0100, Christian Kujau wrote:
> On Tue, 3 Feb 2009, Alex wrote:
> > Thanks for reply. Here is the post, it appears when i try to write into
> > kernel memory. :
>
> Thanks for the Oops. But again, you might have to share a little more
> information, either here on lkml on with the security team. I'm no kernel
> developer but I wonder *what exactly* are you doing to produce this Oops.
>
> > Pid: 3887, comm: insmod Not tainted (2.6.28 #2) HP Pavilion dv2700
>
> Which module did you just insert? Is it your own trying to write to kernel
> memory? Can we see the source of that? However, since you're are root
> anyway to load this module, you can of course do all kinds of shenanigans
> to memory and the kernel might just Oops rightfully so.
>
> Christian.

Sorry Christian, i should have been more explicit the second time, we
are basically building our own kernel module. After finding the system
call table's address, we try to write into kernel memory to redirect to
our own idt handler : here is the main code :

(*p = s_c_t's address)
------------------------------------------
while (!((*p == 0x0f) && (*(p+1) == 0x83)))
p++;
p -= 5; // finding 'cmp' opcode

*p++ = 0x68; // writing push
p2 = (unsigned long *) p;
*p2++ = (unsigned long) ((void *) our_idt); // main hook

p = (unsigned char *) p2;
*p = 0xc3; // writing ret
-------------------------------------------

This code is part of our kernel module, that we want to insert into the
kernel to execute it. It actually works on 2.6.23 kernel, but we
encountered problems while loading this module into the 2.6.28 kernel
(ie: exactly when we try to write 'push' in the code above, we get the
oops).

So yes i think the kernel is reacting rightfully, but i'm trying to
understand why. I'd just want some hints on which security concepts,
that have been taken between 2.6.23 and 2.6.28 in order to prevent those
writings, and hints for bypassing it... I think of time of translation
between virtual & physic addresses kind-of-concepts, but i'm certainly
mistaken.

Basically, we're actually trying to hook system calls on 2.6.28, as a
proof-of-concept for an university project.

Thanks for any hints.

Alex




\
 
 \ /
  Last update: 2009-02-03 18:47    [W:0.331 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site