[kernel] Question about 2.6.28 kernel

[kernel] Question about 2.6.28 kernel

[Alex]

Hi everyone,

I'm currently thinking of ways to hook system calls (PoC) in the linux
kernel 2.6.28. Based on a simple rootkit, which can be executed on the
2.6.23, i got an "oops.. unable to handle kernel paging request at
0x...", when i run it on a new kernel. Can anyone help me finding what
protection was added to prevent writings on kernel memory ? 

Thanks for your help.

Alex

Re: [kernel] Question about 2.6.28 kernel

[Christian Kujau]

On Mon, 2 Feb 2009, Alex wrote:
> kernel 2.6.28. Based on a simple rootkit, which can be executed on the
> 2.6.23, i got an "oops.. unable to handle kernel paging request at
> 0x...", when i run it on a new kernel. Can anyone help me finding what
> protection was added to prevent writings on kernel memory ? 

You could either post the Oops in full and discuss it right here on this 
list or follow the Documentation/SecurityBugs document if this turns out
to be security related.

Christian.
-- 
BOFH excuse #67:

descramble code needed from software company

Re: [kernel] Question about 2.6.28 kernel

[Alex]

On Mon, 2009-02-02 at 21:12 +0100, Christian Kujau wrote:
> On Mon, 2 Feb 2009, Alex wrote:
> > kernel 2.6.28. Based on a simple rootkit, which can be executed on the
> > 2.6.23, i got an "oops.. unable to handle kernel paging request at
> > 0x...", when i run it on a new kernel. Can anyone help me finding what
> > protection was added to prevent writings on kernel memory ? 
> 
> You could either post the Oops in full and discuss it right here on this 
> list or follow the Documentation/SecurityBugs document if this turns out
> to be security related.
> 

Thanks for reply. Here is the post, it appears when i try to write into
kernel memory.  :

BUG: unable to handle kernel paging request at c0403cb8
IP: [<f86af074>] set_idt_handler+0xe/0x22 [module]
*pde = 00911067 *pte = 00403161 
Oops: 0003 [#1] SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-4/dev
Modules linked in: module(+) aes_i586 aes_generic arc4 ecb rt73usb
rt2x00usb rt2x00lib rfkill mac80211 cfg80211 ext2 udf bridge stp bnep
rfcomm l2cap bluetooth tun sunrpc cpufreq_ondemand acpi_cpufreq
dm_mirror dm_region_hash dm_log dm_multipath dm_mod ipv6 snd_hda_intel
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss sr_mod cdrom snd_mixer_oss snd_pcm uvcvideo snd_timer
snd_page_alloc snd_hwdep compat_ioctl32 firewire_ohci firewire_core
video snd videodev i2c_i801 ata_piix battery output v4l1_compat ac sky2
crc_itu_t wmi serio_raw pata_acpi i2c_core soundcore joydev iTCO_wdt
ata_generic iTCO_vendor_support sg ahci libata sd_mod scsi_mod ext3 jbd
mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]

Pid: 3887, comm: insmod Not tainted (2.6.28 #2) HP Pavilion dv2700
Notebook PC
EIP: 0060:[<f86af074>] EFLAGS: 00210246 CPU: 0
EIP is at set_idt_handler+0xe/0x22 [module]
EAX: c0403cbd EBX: c0403c88 ECX: c0781b04 EDX: 017d0000
ESI: f86af155 EDI: 00000000 EBP: f63d2fa0 ESP: f63d2e2c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process insmod (pid: 3887, ti=f63d2000 task=f481be80 task.ti=f63d2000)
Stack:
 f86af1b3 f86af2f0 c04371ea f86af2e3 c0652b00 f86af2d1 c0403b64 f86af2c0
 f86af900 c0401130 00200286 c047f11d 00000044 f6201660 00000001 f63d2e7c
 c047f11d f63e6368 f63e6340 f86af900 f63d2e84 c047f16e f63d2fa0 c044d34f
Call Trace:
 [<f86af1b3>] ? init_module+0x5e/0x6f [module]
 [<c04371ea>] ? sys_kill+0x0/0x12b
 [<c0403b64>] ? ia32_sysenter_target+0x0/0x7
 [<c0401130>] ? _stext+0x48/0x119
 [<c047f11d>] ? __vunmap+0x86/0x8e
 [<c047f11d>] ? __vunmap+0x86/0x8e
 [<c047f16e>] ? vfree+0x25/0x27
 [<c044d34f>] ? load_module+0x1449/0x1616
 [<c043d875>] ? autoremove_wake_function+0x0/0x33
 [<c064d3a5>] ? _spin_lock+0x15/0x18
 [<c04a093c>] ? mntput_no_expire+0x18/0x10e
 [<c049c81c>] ? dput+0xe9/0x13e
 [<c044d5a3>] ? sys_init_module+0x87/0x17a
 [<c0403bdf>] ? sysenter_do_call+0x12/0x2f
Code: 6b f8 8b 50 03 83 c0 07 a3 90 0a 6b f8 eb 01 40 80 38 fa 75 fa a3
8c 0a 6b f8 89 d0 c3 eb 01 40 80 38 0f 75 fa 80 78 01 83 75 f4 <c6> 40
fb 68 eb 01 40 80 78 fc 0f 75 f9 80 78 fd 82 75 f3 c3 eb 
EIP: [<f86af074>] set_idt_handler+0xe/0x22 [module] SS:ESP 0068:f63d2e2c
---[ end trace d8513bd2111b2d4e ]---


Thanks in advance for any hints.

Alex


> Christian.

Re: [kernel] Question about 2.6.28 kernel

[Christian Kujau]

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.
-- 
BOFH excuse #17:

fat electrons in the lines

Re: [kernel] Question about 2.6.28 kernel

[Alex]

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