All of lore.kernel.org
 help / color / mirror / Atom feed
* executing insmod hangs the entire os
@ 2015-02-17 16:16 noyb noybee
  2015-02-17 18:29 ` Valdis.Kletnieks at vt.edu
  0 siblings, 1 reply; 7+ messages in thread
From: noyb noybee @ 2015-02-17 16:16 UTC (permalink / raw)
  To: kernelnewbies

When I execute insmod for the kernel module object file of the
following C code, the entire system hangs. The module replaces the
reference to original chroot system call with a new one in the
sys_call_table. The syscall_table address is correct as per
System.map(which returns 2 values for sys_call_table, surprisingly). I
am on a VM running CentOS 6.6 with kernel version 2.6.32-504.


#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/unistd.h>
#include <asm/cacheflush.h>
#include <asm/page.h>
#include <asm/current.h>
#include <linux/sched.h>
#include <linux/kallsyms.h>

unsigned long *syscall_table = (unsigned long *)0xffffffff81600560;

asmlinkage int (*original_chroot)(const char __user *);

asmlinkage int new_chroot(const char __user *filename){
    printk(KERN_ALERT "CHROOT HIJACKED");
    return (*original_chroot)(filename);
}

static int init(void) {
    printk(KERN_ALERT "\nHIJACK INIT\n");
    original_chroot = (void *)syscall_table[__NR_chroot];
    syscall_table[__NR_chroot] = new_chroot;
    return 0;
}

static void exit(void) {
    syscall_table[__NR_chroot] = original_chroot;
    printk(KERN_ALERT "MODULE EXIT\n");
}

module_init(init);
module_exit(exit);

^ permalink raw reply	[flat|nested] 7+ messages in thread

* executing insmod hangs the entire os
  2015-02-17 16:16 executing insmod hangs the entire os noyb noybee
@ 2015-02-17 18:29 ` Valdis.Kletnieks at vt.edu
  2015-02-18  5:19   ` noyb noybee
  2015-02-18  6:46   ` Saumendra Dash
  0 siblings, 2 replies; 7+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2015-02-17 18:29 UTC (permalink / raw)
  To: kernelnewbies

On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:

> am on a VM running CentOS 6.6 with kernel version 2.6.32-504.

Which probably has kernel relocation and ASLR enabled.

> unsigned long *syscall_table = (unsigned long *)0xffffffff81600560;

So that isn't pointing at the syscall table in the running kernel.

>     syscall_table[__NR_chroot] = new_chroot;

So you just trashed an essentially random location in memory.

You explained in a private email what you were trying to do here - and
I'll point out that it essentially changes the kernel API in unexpected
and undocumented ways.  It even introduces some security holes and bugs (hint -
if you close all file descriptors, what happens to programs that were expecting
stdin/stdout/stderr to be open?  In particular, programs that open, say,
/dev/log so they have syslog output, and then chroot.  Or programs that
open a socket, then chroot and drop permissions (like openssh's sshd for
privilege separation).

You're really not doing yourself a favor with this whack-a-mole approach
to security.  You *really* need to sit down and think about what problem
you're trying to solve here.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150217/13a745b3/attachment.bin 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* executing insmod hangs the entire os
  2015-02-17 18:29 ` Valdis.Kletnieks at vt.edu
@ 2015-02-18  5:19   ` noyb noybee
  2015-02-18  6:46   ` Saumendra Dash
  1 sibling, 0 replies; 7+ messages in thread
From: noyb noybee @ 2015-02-18  5:19 UTC (permalink / raw)
  To: kernelnewbies

On Tue, Feb 17, 2015 at 11:59 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:
>
>> am on a VM running CentOS 6.6 with kernel version 2.6.32-504.
>
> Which probably has kernel relocation and ASLR enabled.
>
>> unsigned long *syscall_table = (unsigned long *)0xffffffff81600560;
>
> So that isn't pointing at the syscall table in the running kernel.
>
>>     syscall_table[__NR_chroot] = new_chroot;
>
> So you just trashed an essentially random location in memory.

Oh no, the memory location is retrieved dynamically every time the
module is compiled and loaded. Also, I am just experimenting with
hooking into system calls here. The project itself is not completed
planned at the moment, like you pointed out.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* executing insmod hangs the entire os
  2015-02-17 18:29 ` Valdis.Kletnieks at vt.edu
  2015-02-18  5:19   ` noyb noybee
@ 2015-02-18  6:46   ` Saumendra Dash
  2015-02-18  7:03     ` noyb noybee
  1 sibling, 1 reply; 7+ messages in thread
From: Saumendra Dash @ 2015-02-18  6:46 UTC (permalink / raw)
  To: kernelnewbies

On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:

>> am on a VM running CentOS 6.6 with kernel version 2.6.32-504.

>Which probably has kernel relocation and ASLR enabled.

>> unsigned long *syscall_table = (unsigned long *)0xffffffff81600560;

>So that isn't pointing at the syscall table in the running kernel.

>>     syscall_table[__NR_chroot] = new_chroot;
 
Leave apart the security holes / undocumented ways etc. raised by Valdis, the way you are getting the address of the syscall table( from System.map), and then changing that will only hang the system.
The syscall table is read only. You need to make it writable by changing the write protection bit in the Control Regs.

Hope it helps.

Thanks,
Saumendra 






::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 7+ messages in thread

* executing insmod hangs the entire os
  2015-02-18  6:46   ` Saumendra Dash
@ 2015-02-18  7:03     ` noyb noybee
  2015-02-18 14:45       ` noyb noybee
  2015-02-18 16:55       ` Valdis.Kletnieks at vt.edu
  0 siblings, 2 replies; 7+ messages in thread
From: noyb noybee @ 2015-02-18  7:03 UTC (permalink / raw)
  To: kernelnewbies

On Wed, Feb 18, 2015 at 12:16 PM, Saumendra Dash <saumendra.d@hcl.com> wrote:
> On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said:
> The syscall table is read only. You need to make it writable by changing the write protection bit in the Control Regs.
Wasn't that implemented from version 3 and not 2.6?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* executing insmod hangs the entire os
  2015-02-18  7:03     ` noyb noybee
@ 2015-02-18 14:45       ` noyb noybee
  2015-02-18 16:55       ` Valdis.Kletnieks at vt.edu
  1 sibling, 0 replies; 7+ messages in thread
From: noyb noybee @ 2015-02-18 14:45 UTC (permalink / raw)
  To: kernelnewbies

On Wed, Feb 18, 2015 at 12:33 PM, noyb noybee <afzalulh@gmail.com> wrote:
> Wasn't that implemented from version 3 and not 2.6?
Apparently not. Sorry for the mistake.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* executing insmod hangs the entire os
  2015-02-18  7:03     ` noyb noybee
  2015-02-18 14:45       ` noyb noybee
@ 2015-02-18 16:55       ` Valdis.Kletnieks at vt.edu
  1 sibling, 0 replies; 7+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2015-02-18 16:55 UTC (permalink / raw)
  To: kernelnewbies

On Wed, 18 Feb 2015 12:33:57 +0530, noyb noybee said:

> Wasn't that implemented from version 3 and not 2.6?

Another problem is you're developing against 2.6. <ducks> :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150218/996ab0df/attachment.bin 

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-02-18 16:55 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-17 16:16 executing insmod hangs the entire os noyb noybee
2015-02-17 18:29 ` Valdis.Kletnieks at vt.edu
2015-02-18  5:19   ` noyb noybee
2015-02-18  6:46   ` Saumendra Dash
2015-02-18  7:03     ` noyb noybee
2015-02-18 14:45       ` noyb noybee
2015-02-18 16:55       ` Valdis.Kletnieks at vt.edu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.