linux-kernel - Re: [kernel] Question about 2.6.28 kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1233682030.28905.59.camel@localhost.localdomain>
Date:	Tue, 03 Feb 2009 18:27:10 +0100
From:	Alex <eosyop@...il.com>
To:	Christian Kujau <lists@...dbynature.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [kernel] Question about 2.6.28 kernel

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/