Text relocations in kernel modules

Peter Wemm peter at wemm.org
Mon Apr 2 22:08:38 UTC 2012


On Mon, Apr 2, 2012 at 1:02 PM, Richard Yao <ryao at cs.stonybrook.edu> wrote:
> 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.

ASLR is a generic term for a worthwhile goal - to raise the difficulty
bar for an attacker to do something meaningful when they find a
vulnerability that leads to the ability to inject code.  There's
people actively working on this in FreeBSD, but it has nothing to do
with the DT_TEXTREL in an i386 .ko file.

I wasn't the one who brought up ASLR, you keep bringing it up without
a single DETAIL about why it's relevant.  And then dismissing all of
the details we provide to explain, in detail, why DT_TEXTREL on a .ko
file has nothing to do with ASLR.


> 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.

I don't believe you.  The way I see it,  either:
1) you asked the wrong people who are as misguided as you are, or
2) you told them what they'd need to hear in order to arrive at the
conclusion you want, or
3) you're making it up.

I find it hard to believe that seasoned folks who wrote the
excellently detailed 'how to fix' page for USERLAND libraries at
http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml would make
such a colossal mistake.  If such an opinion was actually expressed to
you, I think its far more likely it was based on a lack of working
knowledge of what a freebsd .ko file is and how its used, or based on
misinformation from you.  Or you asked the wrong people.

A http url link to the mailing list archives would be greatly
appreciated, so I can find out exactly what the source of this
insanity is.

> My original email to the list asked if this was an issue in FreeBSD.
> That question had been answered.

Yes, it has been answered. No, not a bug, not a security issue, and
not even the slightest cause for concern in any way, and does not in
any way interfere with ASLR type goals.

> 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.

That's akin to saying: "I'm going to drown your neighbor's cousin's
daugher's pet kitten if you don't put a better muffler on your car."

Nobody's disputing that ASLR is a worthwhile thing. What we're
disputing is your unfounded, unsupported assertion that a DT_TEXTREL
is a cause for concern in a kernel module.

What people reacted to was your stubborn unwillingness to accept that
you were wrong when you were told you were wrong by something
approaching six different people now, with explicit details about how
you were wrong.  "Because I said so" isn't a valid rebuttal.

> However, there could be unknown exploits in the wild that would be
> killed by ASLR in the wild.

Ah, here we go again. You bring up ASLR again.

I find it hard to believe your "I might write an exploit" threat to be
credible when you can't provide any details and don't seem to be able
to demonstrate understanding of any of the basic concepts.

Repeat: ASLR is good.  But your DT_TEXTREL bug report in a .ko file is
not a bug and has nothing to do with ASLR in any way, shape, form,
variant or technique.  Your tools are for USERLAND shared libraries,
and a .ko file not a USERLAND shared library.

There's a multitude of things to complain about in the .ko file
loader, but DT_TEXTREL is not one of them.

The FreeBSD project isn't in the habit of making changes based on
vague hand-waving, fear mongering and threats in the face of detailed,
considered reason why it shouldn't be changed.

I'm happy to talk details about why it's a problem, but I don't
believe they exist.  I'm happy to be proven wrong on that.

-- 
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


More information about the freebsd-stable mailing list