LKM insecurity

["Greg A. Woods" <woods () weird com>]

[ On Saturday, January 6, 2001 at 01:17:59 ( -0800), Aaron wrote: ]
> Subject: Re: yes, its t0rn again
>
> Not only could removing module support make system maintenance a pain,

No modern open-source system requires loadable kernel module support,
and not having them doesn't induce any pain (at least none that I've
been able to detect).

The only point to LKM's on open-source systems seems to be to make
kernel programmers happier.  Of course they can make it easier to muck
about with proprietary binary-only kernels (or binary-only modules) too,
but then we wouldn't be talking about open-source systems would we!  :-)

In fact LKM's are not required in any modern open-source system which is
being used to provide a secure computing service (and any idiot trying
to do kernel testing on a production system will hopefully eventually
get their just desserts! :-).

> but
> it isn't sufficient to stop the kernel from being modified after startup.
> Silvio Cesare wrote a paper in Nov '98 that discusses how to do this
> via direct writes to /dev/*mem:
>
>   Runtime Kernel kmem Patching
>   http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt

Sure you can hack /dev/kmem to alter a running kernel in some
cirumstances, but /dev/kmem can trivially be made unwritable by
unprivileged users and it's unwritable by even the superuser on *BSD
with the appropriate securelevel setting.  So, provided that the system
under attack has this securelevel feature, and it has been appropriately
turned on, any attempts to modify the running kernel will be entirely
thwarted before they can even begin.

The point of removing loadable kernel module support entirely (and from
booting from secure media) is to ensure that the kernel starts up and
continues to run in a secure manner -- i.e. to ensure its integrity not
only through the boot process, but also through the lifetime of the
running system too.  There has been some research investigating the
viability of using secure digital signatures to validate the body of an
LKM, but such techniques are either hackable themselves, or require that
the signatures be communicated to the kernel "out-of-band" (eg. they are
loaded into the kernel image before it's put on the secure media it will
be booted from).

I suppose /dev/lkm (or whatever modload(8) uses on non-*BSD systems)
could be made unwritable or unusable with securelevel >= 1 too, thus
potentially making it safer to load kernel modules at boot time from
whatever secure media the main kernel itself is loaded from, but there
doesn't seem to be any point to doing this in any open-source
environment that's not being used for kernel testing.

In any case the implication is that once a secured system is running in
multi-user mode there should never be any opportunity for any user-level
process to modify kernel memory (be it the data or text segments) in any
way whatsoever, and thus that if you find not having LKM's to be a
maintenance pain then you'll find maintenance on any secure system to be
a pain.

I.e. if you can't use LKM's after boot, and if you don't need them in
any open-source in the first place, and if you're not doing kernel
development, why bother even supporting them?  They only increase
complexity and that alone can make the system less secure, never mind
that any vulnerabilities in the LKM mechanism would make the system
vulnerable to its very core.

--
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>      <robohack!woods>
Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>