[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux-security] Malicious Linux modules (fwd)
At 01:11 PM 10/12/97 +0200, you wrote:
>> Well, judging by this code portion, the easiest way to eliminate the
>> possiblity of such abusive behaviour is to modify the kernel so it will not
>> use sys_call_table at all. I.e: when the kernel receives a signal it is
>> forwarded to the corresponding handler by using a switch() statement,
>> rather than an array of pointers to function. That way, it will be
>> impossible to alter the handlers, at least with such ease.
>>
>> I'm not an expert at the Linux kernel architecture, so don't flame me if
>> this idea cannot be implemented for some reason.
>
>I'm no expert either, but I suspect that this feature was put in the Linux
>kernel for a reason, most probably other modules use it too (grep the
>source tree?).
>
Well, I've scanned the kernel tree and realized that sys_call_table is
defined in the arch/i386/kernel/entry.S, which is an Assemble file. (it may
vary for platforms other than x86's) It is also referenced in
kernel/ksyms.c which is a module that is used to export symbols to
dynamically linked kernel modules.
I patch entry.S so it will not use sys_call_table but rather a simplistic
assembly "switch" construct. I recompiled the kernel with it and it
compiled fine. I didn't have time to test it yet, but I'll let you guys
know after I tried running Linux with the modified kernel.
According to Peter: "The syscall table is the only compatibility point for
statically linked code. It is also the compatibility point for library
functions for dynamically linked code. It is the compatibility point for
IBCS. In other words, you can't change it."
>From what I've seen in the code, it is only used internally within the
kernel, and as I said was not referenced outside entry.S. Still, Peter may
be right about it. As a final note, this patch probably doesn't completely
remove the risk of Malicious kernel modules. For example, it may be
possible to modify the code of a function by using "memcpy((void*)sys_open,
strMyOpenCode)". Still, if it works it will make it harder on hackers and
the like.
Shlomi Fish
-----------------------------------------------------------------------------
Shlomi Fish Smart Link Ltd.
Home E-mail: shlomif@ibm.net Work E-mail: shlomi@slink.co.il
Home Page: http://www.slink.co.il/~shlomi
"If I had not been insane already, I would have long ago driven myself mad."
The Enemy and how I Helped to Fight it.
-----------------------------------------------------------------------------