Text relocations in kernel modules

[Peter Wemm]

On Wed, Apr 4, 2012 at 10:34 AM, jb <jb.1234abcd at gmail.com> wrote:
> Peter Wemm <peter <at> wemm.org> writes:
>
>> ...
>> There is no way to interfere because it is done outside of user space
>> entirely, **after** the file has been copied out of the file system.
>> You can do whatever you like to the file, but it has no effect because
>> all the relocation is done in a private kernel copy.
>> ...
>
> What if attack code (broadly understood) is part of module code, and is based
> on either or both of:
> - hidden (as to meaning and reloc targets) arrangement of relocations needed
> - has an ability of (self) activation during load/link and *relocations* process
> already under the privilege of the kernel ?
>
> Is that possible at all ?
> Would there be any protection against it (except giving up relocations as
> an enabling vehicle) ?

1) If you can convince the superuser directly or indirectly to load a
.ko file of your creation or under your control, it doesn't matter
what the relocation state is. You already own the machine.
2) If you can write to kernel memory, you already own the machine,
regardless of relocations.
3) There is no difference in any way between a text relocation and a
non-text relocation inside kernel mode.
4) The user doesn't have any influence over the relocation process in
any way except by #1 and #2, in which case relocations don't matter,
because you already own the machine.
5) If you own the machine's kernel, you can hide anything you wish.
Relocations are not a factor in this.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell