kpneal at 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 Wed, 2012-04-04 at 08:38 +, jb wrote:
kpneal at 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
Ian Lepore freebsd at 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 code
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
On Wed, 2012-04-04 at 15:05 +, jb wrote:
Ian Lepore freebsd at 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 jb.1234a...@gmail.com wrote:
kpneal at 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.
On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore
free...@damnhippie.dyndns.org 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
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
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 jb.1234a...@gmail.com wrote:
Peter Wemm peter at wemm.org writes:
...
There is no way
On Wed, Apr 4, 2012 at 10:34 AM, jb jb.1234a...@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
Peter Wemm peter at 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
___
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao r...@cs.stonybrook.edu 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
On 04/02/12 05:56, Tom Evans wrote:
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao r...@cs.stonybrook.edu 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
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 r...@cs.stonybrook.edu 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 Mon, Apr 2, 2012 at 5:49 PM, Richard Yao r...@cs.stonybrook.edu wrote:
On 04/02/12 05:56, Tom Evans wrote:
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao r...@cs.stonybrook.edu wrote:
There are no security implications, no system resources to be wasted.
And if you think there are security
On 04/02/12 13:13, Tom Evans wrote:
On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao r...@cs.stonybrook.edu wrote:
On 04/02/12 05:56, Tom Evans wrote:
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao r...@cs.stonybrook.edu wrote:
There are no security implications, no system resources to be wasted.
On Fri, Mar 30, 2012 at 7:42 PM, Richard Yao r...@cs.stonybrook.edu wrote:
On 03/30/12 22:15, Peter Wemm wrote:
On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao r...@cs.stonybrook.edu wrote:
On 03/30/12 18:46, Konstantin Belousov wrote:
Reread what I wrote to you. Also, it pays off learning how
On Mon, Apr 2, 2012 at 10:31 AM, Richard Yao r...@cs.stonybrook.edu wrote:
On 04/02/12 13:13, Tom Evans wrote:
On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao r...@cs.stonybrook.edu wrote:
On 04/02/12 05:56, Tom Evans wrote:
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao r...@cs.stonybrook.edu
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
On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao r...@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
On 04/02/12 15:37, Peter Wemm wrote:
On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao r...@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
On Mon, Apr 2, 2012 at 1:02 PM, Richard Yao r...@cs.stonybrook.edu wrote:
On 04/02/12 15:37, Peter Wemm wrote:
On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao r...@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
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
Dynamic section at offset 0x2f6c contains 13 entries:
TagType Name/Value
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
Dynamic section at offset 0x2f6c contains
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
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 that something is
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 consider this a bug ?
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 tags are
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 3:47 PM, Richard Yao r...@cs.stonybrook.edu 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
On Fri, Mar 30, 2012 at 6:51 PM, kpn...@pobox.com 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
On 03/30/12 22:15, Peter Wemm wrote:
On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao r...@cs.stonybrook.edu 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
33 matches
Mail list logo
