Relocatable kernels - how much difference does it make?

Discussion in 'all things UNIX' started by Gullible Jones, Aug 21, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Code:
    % grep RELOCATABLE /boot/config-3.2.0-4-amd64 
    CONFIG_RELOCATABLE=y
    As you can see here from a kernel Makefile:
    http://lxr.free-electrons.com/diff/arch/x86/Makefile?v=3.9;diffval=powerpc;diffvar=a

    this makes the kernel a position independent executable (PIE). How much difference does this make vs. the chance of success for common types of kernel memory exploits?

    e.g. I'd imagine that it might make it chancier to exploit a dangling pointer or use-after-free bug, since as with ASLR you don't know where the malicious code will land? It can't just be a matter of relative positioning within the kernel, I think, since your attack has to start off in user space.

    OTOH it looks like modules are still loaded into predictable positions, so my hunch is this wouldn't do anything about an exploit against a driver compiled as a module...

    Can anyone provide further info?
     
  2. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,094
    Even in the case where an exploit exists against a driver compiled as a module - in order to apply the exploit against the driver, it would have to find it first, eh? What proof is there that modules are loaded into predictable positions with regard to relocatable kernels?

    -- Tom
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Modules are specifically not compiled as PIE. Or does that not matter? Would the module's base position in memory be randomized as long as the the kernel itself is PIE?
     
  4. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,094
    As I understand it, a stack internal to the kernel's memory is used to keep track of where modules are loaded. Where a module is loaded depends on the space available in which to load and operate it. At runtime, where modules are always dynamically loaded in the same order, the necessary information in the stack as to each modules load location would have to be found after identifying the stack's location, and where load order is not always in a set order, the attacker would still have to be able to differentiate a target module's signature to determine it has the desired target.
     
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    So they really are dynamic. Cool. And thanks :)
     
  6. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Think about ASLR. In 32bit address spaces we focus so much on entropy because ~4GB is such a tiny space.

    The kernel has 2GB address space. It also has 8bits of entropy for randomization.

    It is also one contiguous blob

    So, do I have to say how useful it is?

    edit2: Also, keep in mind that the kernel boots up... well, early. So where's the entryop for the KASLR coming from? With Grsecurity you get a bit of an improvement here, but vanilla kernel's boned.

    edit: Kernel modules do not have significant entropy typically, they are vmalloc'd objects (and therefor randmoized as such) that are typically loaded before entropy is significant - very early in the boot process. They are in the kernel address space, a smaller portion of it, so, again, not a lot of entropy here.
     
    Last edited: Aug 23, 2014
Loading...
Thread Status:
Not open for further replies.