Text relocations in kernel modules

Ian Lepore freebsd at damnhippie.dyndns.org
Wed Apr 4 15:58:17 UTC 2012


On Wed, 2012-04-04 at 15:05 +0000, jb wrote:
> Ian Lepore <freebsd <at> damnhippie.dyndns.org> writes:
> 
> > ...
> > > But of interest to me is this:
> > > "...
> > > Text relocations are a way in which references in the executable code to
> > > addresses not known at link time are solved. Basically they just write
> > > the appropriate address at runtime marking the code segment writable in
> > > order to change the address then unmarking it. This can be a problem as
> > > an attacker could try to exploit a bug when the text relocation happens
> > > in order to be able to write arbitrary code in the text segment which
> > > would be executed.
> > > ..."
> > ... 
> > A kernel module is loaded and linked
> > ONCE, at load time, into the kernel's address space.
> > ...
> 
> >From the point of view of an attacker it does not matter whether kernel module
> is loaded and linked once only. That's enough to create a window of opportunity
> for interfering with relocation process and modifying text (code).
> 
> jb

Read again what I said.  The same relocations would happen whether
scattered through the text segment or gathered together in a single
page.  So the same window exists either way.

But even more to the point: the memory has to be writable to initially
populate it.  The fact that it has to be changed as it is loaded doesn't
in any way create an opportunity that doesn't already exist due to the
pages being writable so that they can be loaded from disk.  

If there is some malicious in-kernel code (and it MUST be in-kernel
code, because this is kernel memory, not mapped into any userland
address space) it can already write to those pages because they're
writable so that IO can happen. The pages are only visible to kernel
code, and thus this hypothetical attack is being carried out by kernel
code; if the pages weren't marked writable it would just make them
writable, then write to them.  

If there is malicious in-kernel code that wants to do bad things, it
doesn't have to wait for a .ko to get loaded to do the bad things.  It's
kernel code, it can do whatever it wants whenever it wants.

This whole relocation question is just a big red herring.  The kernel
loader relocating a kernel module at load time does not open any
opportunity for userland code to launch an attack on the memory pages
into which the module gets loaded.

-- Ian




More information about the freebsd-stable mailing list