Text relocations in kernel modules

[Richard Yao]

On 04/02/12 15:37, Peter Wemm wrote:
> On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao <ryao at cs.stonybrook.edu> wrote:
>> On 04/02/12 14:46, Peter Wemm wrote:
>>> Remember.. ASLR is a userland thing.  .ko files, which is what this
>>> thread is about, already use random address layout.  When you do a
>>> "kldload virtio.ko", you have no way to predict what address it will
>>> be loaded at.  And you don't even have access to the addresses.
>>>
>>> Of course if you want to talk about ASLR and userland .so files then
>>> that's an entirely different thing.  But this thread is about your
>>> tools finding DT_TEXTREL in a .ko kernel file, not userland .so files.
>>>
>>
>> The PaX project's patches to the Linux kernel include kernel stack
>> randomization. The Gentoo Hardened project makes use of this in their
>> fork of the Linux kernel.
>>
> 
> I looked at their code, and their description here:
> http://pax.grsecurity.net/docs/randkstack.txt
> 
> Of note:
> "pax_randomize_kstack() gathers entropy from the rdtsc instruction
> (read time stamp counter) and applies it to bits 2-6 of the kernel
> stack pointer. This means that 5 bits are randomized providing a
> maximum shift of 128 bytes - this was deemed safe enough to not cause
> kernel stack overflows  yet give enough randomness to deter
> guessing/brute forcing attempts."
> 
> This has nothing to do with the DT_TEXTREL in .ko that this thread is
> about and has no bearing on ASLR in any way.

There are plenty of techniques employed to do ASLR by both the upstream
Linux kernel and the PaX patches to it. I only needed to state one to
prove that you were wrong about ASLR being exclusive to userland.

If the QA checks had been triggered for an out-of-tree Linux kernel
module, the Gentoo developers would consider it to be a bug. I have
verified this with the Gentoo Hardened developers. Furthermore, they
confirmed that text relocations in out-of-tree kernel modules would
negatively affect ASLR.

My original email to the list asked if this was an issue in FreeBSD.
That question had been answered. However, people went ballistic upon the
mere presence of my question, so I assured them that if I ever found
time to write exploit code, I would do full disclosure to ensure that
this issue was fixed.

I stumbled across this issue when setting up an environment in which I
could port gptzfsloader to Linux, so I have no reason to implement ASLR
in the FreeBSD kernel. Also, the abuse I received over this has lead me
to conclude that doing anything for upstream would be deterimental to my
mental health, so I am not inclined to try.

However, there could be unknown exploits in the wild that would be
killed by ASLR in the wild. It would be best for someone, who considers
securing FreeBSD to be worth suffering from abuse, to implement it. That
person is not me.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120402/27e225e3/signature.pgp