modules

Jörg W Mittag Joerg.Mittag at Web.De
Tue Jan 6 17:42:22 PST 2004


Ian Molton wrote:
> On Tue, 06 Jan 2004 16:14:11 -0500
> Robert Connolly <cendres at videotron.ca> wrote:
>> I forget where i read it too. Disabling kernel loadable modules
>> minimizess functionality of the kernel, and makes it slightly harder
>> for an attacker to inject code.
> Might want to remove /dev/kmem then.
> 
> but we've been here before... to insert code into the kernel you MUST BE
> ROOT ALREADY. 
> 
> There is no other way that wouldnt be exploitable as any user in any
> case.
> 
> I really dont see the point in trying to defend against someone who
> already has root. what more could they want? in many cases they could
> simply replace the kernel and issue a reboot!

I think there's actually two seperate issues here. The one is about
inserting arbitrary code in the kernel. The other is about security flaws in
the module handling code.

Let's look at number one first. Like Ian has already said, arbitrary code
can be inserted in the kernel whether modules are enabled or disabled.
(Actually, IIRC Alan Cox once mentioned that there are exploits around which
make inserting modules in module-less kernels so easy that they could almost
be used as a drop-in replacement for insmod.) You just need CAP_SYS_RAW. So,
since disabling modules doesn't prevent someone with CAP_SYS_RAW from
inserting code in the kernel and he needs to have CAP_SYS_MODULE (both
capabilities usually mean that you're root anyway, at least in a non-MAC
system) anyway, even *with* modules enabled, there's not much point in
disabling modules.

However, *if* there are security flaws in the module handling code itself,
disabling modules will also disable these flaws. Now, how could someone
exploit security flaws in the module handling code, if he doesn't have the
necessary capabilities to handle modules? Well, he could let the kernel do
it for him, e.g. via module autoloading and/or hotplugging. So, the only
case where an attacker could force a module being loaded, is *if* module
autoloading is compiled into the kernel *and if* module autoloading is not
disabled *and if* the module has not already been loaded *and if* he's able
to trigger some action which loads this module - that is a lot of ifs. Only
then can he exploit a flaw in the module handling code. Disabling modules
can prevent this. However, even in this case, it is not necessary since
there are less invasive solutions. Module autoloading and hotplugging (or
coldplugging in this case) on servers or firewalls is usually only needed at
boot time, which means you could simply disable it (echo "/bin/false" >
/proc/sys/kernel/modprobe or /proc/sys/kernel/hotplug) at the end of
runlevel 2, before bringing up the network or any local or remote login
shells. Alan Cox once also mentioned the possibility of writing a kernel
module which disables module loading and loading this module at the end of
the boot process and before bringing up the network. You can also remove the
respective capabilities with something like "echo 0xFFFE7FFF ?>
/proc/sys/kernel/cap-bound".

What it comes down to is that it's a matter of taste, whether you enable
modules or not. From a security point of view, it doesn't actually matter
much. From an availability point of view, a heavily modularized kernel
allows you to possibly unload a buggy module and load a fixed one, without
having to reboot. Of course, this doesn't buy you much, if there are
security flaws in the core part of the kernel, like in the memory management
system, where they unfortunately usually tend to be.

jwm
-- 
perl-5.8.1% ./configure.gnu
Checking to see how your cpp does stuff like concatenate tokens...
Oh!  Smells like ANSI's been here.



More information about the hlfs-dev mailing list