Peter Wemm wemm.org> writes:
> ...
> 5) If you own the machine's kernel, you can hide anything you wish.
> Relocations are not a factor in this.
>
OK. Thanks a lot guys for sharing your answers and time.
It was quite interesting.
jb
___
freebsd-stab
On Wed, Apr 4, 2012 at 10:34 AM, jb wrote:
> Peter Wemm 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 bec
If there is malicious code in a kernel module, then discussions of
relocations become moot.
Sent from my Android 4.0 device. Please forgive any spelling or grammatical
errors.
On Apr 4, 2012 11:35 AM, "jb" wrote:
> Peter Wemm wemm.org> writes:
>
> > ...
> > There is no way to interfere because
Peter Wemm 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 kern
On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore
wrote:
[..]
> 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 loa
On Wed, Apr 4, 2012 at 8:05 AM, jb wrote:
> Ian Lepore 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
>>
On Wed, Apr 4, 2012 at 1:38 AM, jb wrote:
> pobox.com> writes:
>
>> ...
>> You can appeal to authority by saying the Gentoo Hardened developers said
>> such-and-such all you want, but it would be more useful for you to be able
>> to make specific technical arguments yourself. Saying "it could be
On Wed, 2012-04-04 at 15:05 +, jb wrote:
> Ian Lepore 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
jb wrote:
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).
Well yes but said attacker has to be able to modify KERNEL
Ian Lepore 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 co
On Wed, 2012-04-04 at 08:38 +, jb wrote:
> pobox.com> writes:
>
> > ...
> > You can appeal to authority by saying the Gentoo Hardened developers said
> > such-and-such all you want, but it would be more useful for you to be able
> > to make specific technical arguments yourself. Saying "it c
pobox.com> writes:
> ...
> You can appeal to authority by saying the Gentoo Hardened developers said
> such-and-such all you want, but it would be more useful for you to be able
> to make specific technical arguments yourself. Saying "it could be a
> problem" or "in the wild there may be" isn't
On Mon, Apr 2, 2012 at 1:02 PM, Richard Yao wrote:
> On 04/02/12 15:37, Peter Wemm wrote:
>> On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao 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 rand
On 04/02/12 15:37, Peter Wemm wrote:
> On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao 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",
On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao 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
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 t
On Mon, Apr 2, 2012 at 10:31 AM, Richard Yao wrote:
> On 04/02/12 13:13, Tom Evans wrote:
>> On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote:
>>> On 04/02/12 05:56, Tom Evans wrote:
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao
wrote:
>> There are no security implications, no sys
On Fri, Mar 30, 2012 at 7:42 PM, Richard Yao wrote:
> On 03/30/12 22:15, Peter Wemm wrote:
>> On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wrote:
>>> On 03/30/12 18:46, Konstantin Belousov wrote:
Reread what I wrote to you. Also, it pays off learning how ELF works
before making conclusi
On 04/02/12 13:13, Tom Evans wrote:
> On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote:
>> On 04/02/12 05:56, Tom Evans wrote:
>>> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote:
> There are no security implications, no system resources to be wasted.
>
> And if you think there ar
On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote:
> On 04/02/12 05:56, Tom Evans wrote:
>> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote:
There are no security implications, no system resources to be wasted.
And if you think there are security implications, then lets see a
>>
Let's all calm down here. No need to make this personal. Let's please try
to keep this conversation professional and respectful to all parties
involved.
Richard, I suggest that if you think the current implementation is less
secure than other implementations, you could write a patch and submit it
On 4/2/12 12:49 PM, Richard Yao wrote:
> On 04/02/12 05:56, Tom Evans wrote:
>> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote:
There are no security implications, no system resources to be wasted.
And if you think there are security implications, then lets see a
proof-of-c
On 04/02/12 05:56, Tom Evans wrote:
> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote:
>>> There are no security implications, no system resources to be wasted.
>>>
>>> And if you think there are security implications, then lets see a
>>> proof-of-concept.
>>
>> If I find time to write a proof-
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote:
>> There are no security implications, no system resources to be wasted.
>>
>> And if you think there are security implications, then lets see a
>> proof-of-concept.
>
> If I find time to write a proof-of-concept, I promise to publish it
> public
On 03/30/12 22:15, Peter Wemm wrote:
> On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wrote:
>> On 03/30/12 18:46, Konstantin Belousov wrote:
>>> Reread what I wrote to you. Also, it pays off learning how ELF works
>>> before making conclusion from the absence of the output of readelf -d.
>>> Amd64
On Fri, Mar 30, 2012 at 6:51 PM, wrote:
> On Fri, Mar 30, 2012 at 06:47:15PM -0400, Richard Yao wrote:
>> On 03/30/12 18:46, Konstantin Belousov wrote:
>> > Reread what I wrote to you. Also, it pays off learning how ELF works
>> > before making conclusion from the absence of the output of readelf
On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wrote:
> On 03/30/12 18:46, Konstantin Belousov wrote:
>> Reread what I wrote to you. Also, it pays off learning how ELF works
>> before making conclusion from the absence of the output of readelf -d.
>> Amd64 modules _are not_ shared objects.
>
> Wheth
On 03/30/12 18:46, Konstantin Belousov wrote:
> Reread what I wrote to you. Also, it pays off learning how ELF works
> before making conclusion from the absence of the output of readelf -d.
> Amd64 modules _are not_ shared objects.
Whether or not they are shared objects is irrelevant. The fact is
On Fri, Mar 30, 2012 at 06:34:55PM -0400, Richard Yao wrote:
> On 03/30/12 16:36, Konstantin Belousov wrote:
> > First, there _are_ relocations against text in the amd64 modules, but I
> > suspect that your scripts do not detect this. Most likely, scripts look
> > for DT_TEXTREL dynamic tag, and ta
On Fri, Mar 30, 2012 at 04:11:29PM -0400, Richard Yao wrote:
> On 03/30/12 15:46, Konstantin Belousov wrote:
> > On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote:
> >> On 03/30/12 15:07, Konstantin Belousov wrote:
> Is this a bug?
> >>> No. This is by design.
> >>>
> >>> Why do you
On 03/30/12 15:46, Konstantin Belousov wrote:
> On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote:
>> On 03/30/12 15:07, Konstantin Belousov wrote:
Is this a bug?
>>> No. This is by design.
>>>
>>> Why do you consider this a bug ?
>>
>> It occurs on i386, but not amd64. It could be t
On 03/30/12 15:07, Konstantin Belousov wrote:
>> Is this a bug?
> No. This is by design.
>
> Why do you consider this a bug ?
It occurs on i386, but not amd64. It could be that something is wrong
with how things are being compiled i386, or it could be that i386
requires things to be compiled this
eeBSD, which has made collaboration difficult.
>
> With that said, Gentoo Portage is warning about text relocations in
> kernel modules. This is in a Gentoo/FreeBSD port of
> emulators/freebsd-kmod that I wrote. For instance, I see:
>
> # readelf -d /boot/modules/virtio.ko
warning about text relocations in
kernel modules. This is in a Gentoo/FreeBSD port of
emulators/freebsd-kmod that I wrote. For instance, I see:
# readelf -d /boot/modules/virtio.ko
Dynamic section at offset 0x2f6c contains 13 entries:
TagType Name/Value
34 matches
Mail list logo
