From: John Richard Moser <nigelenki@comcast.net>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Rik van Riel <riel@redhat.com>,
linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: Patch 4/6 randomize the stack pointer
Date: Sat, 29 Jan 2005 12:04:00 -0500 [thread overview]
Message-ID: <41FBC200.9050404@comcast.net> (raw)
In-Reply-To: <1107017218.4174.130.camel@laptopd505.fenrus.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>
>>Arjan van de Ven wrote:
>>
>>>>I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
>>>>that I installed, and it FAILED every test. After a while, spender
>>>>reminded me about PT_GNU_STACK. It failed everything but the Executable
>>>>Stack test after execstack -c *. The randomization tests gave
>>>>13(heap-etexec), 16(heap-etdyn), 17(stack), and none for main exec
>>>>(etexec,et_dyn) or shared library randomization.
>>>
>>>
>>>because you ran prelink.
>>>and you did not compile paxtest with -fPIE -pie to make it a PIE
>>>executable.
>>>
>
>
> what I get is
>
> Executable anonymous mapping : Killed
> Executable bss : Killed
> Executable data : Vulnerable
> Executable heap : Killed
> Executable stack : Killed
> Executable anonymous mapping (mprotect) : Vulnerable
> Executable bss (mprotect) : Vulnerable
> Executable data (mprotect) : Vulnerable
> Executable heap (mprotect) : Vulnerable
> Executable shared library bss (mprotect) : Vulnerable
> Executable shared library data (mprotect): Vulnerable
> Executable stack (mprotect) : Vulnerable
> Anonymous mapping randomisation test : No randomisation
> Heap randomisation test (ET_EXEC) : 13 bits (guessed)
> Heap randomisation test (ET_DYN) : 13 bits (guessed)
> Main executable randomisation (ET_EXEC) : 12 bits (guessed)
> Main executable randomisation (ET_DYN) : 12 bits (guessed)
> Shared library randomisation test : 12 bits (guessed)
> Stack randomisation test (SEGMEXEC) : 17 bits (guessed)
> Stack randomisation test (PAGEEXEC) : 17 bits (guessed)
> Return to function (strcpy) : paxtest: bad luck, try
> different compiler options.
> Return to function (strcpy, RANDEXEC) : paxtest: bad luck, try
> different compiler options.
> Return to function (memcpy) : Vulnerable
> Return to function (memcpy, RANDEXEC) : Vulnerable
> Executable shared library bss : Killed
> Executable shared library data : Killed
> Writable text segments : Vulnerable
>
>
> I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> it's way better than what you get in your tests (this is the desabotaged
> 0.9.6 version fwiw)
>
I used 0.9.6 too, it had a slight bug in the randomization test
(getmain.c), which I pointed out in another post.
void foo( int unused )
{
printf( "%p\n", __builtin_return_address(0) );
//printf( "0x%08x\n", ((unsigned long*)&unused)[-1] );
}
I'm curious as to what the hell you're doing to get these results. Exec
Shield came with the sysctl sys/kernel/exec-shield = 1 and
sys/kernel/exec-shield-randomize = 1. I tried exec-shield = 0, 1, 2,
and 3 and couldn't get anything but the stack to kill on a Barton cored
32 bit athlon xp.
The tests I did were on a Fedora Core 3 i net-installed last night, no
adulteration. Whatever black magic you're doing, it's not working here.
>
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB+8H/hDd4aOud5P8RAlIEAJkBwhIxdrXZ+jNz46oRg1SoSPmOHQCgiWfJ
HxzCBB43i6iLLhli5boKzoM=
=etT7
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2005-01-29 17:03 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-27 10:11 Patch 0/6 virtual address space randomisation Arjan van de Ven
2005-01-27 10:12 ` Patch 1/6 introduce sysctl Arjan van de Ven
2005-01-27 10:36 ` Andi Kleen
2005-01-27 11:13 ` Arjan van de Ven
2005-01-27 18:16 ` Pavel Machek
2005-01-27 19:11 ` Ingo Molnar
2005-01-27 19:46 ` Dave Jones
2005-01-27 19:53 ` Ingo Molnar
2005-01-27 19:53 ` Arjan van de Ven
2005-02-04 21:27 ` Benoit Boissinot
2005-01-27 10:12 ` Patch 2/6 introduce helper infrastructure Arjan van de Ven
2005-01-27 10:41 ` Andi Kleen
2005-01-27 11:58 ` Arjan van de Ven
2005-01-27 12:27 ` Andi Kleen
2005-01-27 12:43 ` Arjan van de Ven
2005-02-01 21:14 ` Matt Mackall
2005-01-27 10:12 ` Patch 3/6 per process flag Arjan van de Ven
2005-01-27 10:13 ` Patch 4/6 randomize the stack pointer Arjan van de Ven
2005-01-27 10:21 ` Christoph Hellwig
2005-01-27 17:38 ` John Richard Moser
2005-01-27 17:47 ` Arjan van de Ven
2005-01-27 18:04 ` John Richard Moser
2005-01-27 18:09 ` Arjan van de Ven
2005-01-27 18:12 ` Christoph Hellwig
2005-01-27 18:16 ` Linus Torvalds
2005-01-27 18:28 ` Linus Torvalds
2005-01-27 18:55 ` John Richard Moser
2005-01-27 18:49 ` John Richard Moser
2005-01-27 19:30 ` Linus Torvalds
2005-01-27 19:48 ` Arjan van de Ven
2005-01-27 19:59 ` Linus Torvalds
2005-01-27 20:04 ` Arjan van de Ven
2005-01-27 20:08 ` John Richard Moser
2005-01-27 19:19 ` linux-os
2005-01-27 19:52 ` Julien TINNES
2005-01-27 20:02 ` Arjan van de Ven
2005-01-27 20:13 ` John Richard Moser
2005-01-27 21:33 ` jnf
2005-01-28 17:22 ` Paulo Marques
2005-01-28 17:51 ` John Richard Moser
2005-01-28 18:42 ` Ingo Molnar
2005-01-29 6:04 ` John Richard Moser
2005-01-27 20:37 ` linux-os
2005-01-27 20:45 ` John Richard Moser
2005-01-27 21:39 ` John Richard Moser
2005-01-27 21:53 ` Arjan van de Ven
2005-01-27 22:34 ` John Richard Moser
2005-01-29 2:50 ` Rik van Riel
2005-01-29 6:31 ` John Richard Moser
2005-01-29 8:10 ` Arjan van de Ven
[not found] ` <41FBB821.3000403@comcast.net>
2005-01-29 16:42 ` Arjan van de Ven
2005-01-29 16:59 ` John Richard Moser
2005-01-29 16:46 ` Arjan van de Ven
2005-01-29 17:04 ` John Richard Moser [this message]
2005-01-29 17:37 ` Jakub Jelinek
2005-01-29 17:49 ` John Richard Moser
2005-01-29 17:55 ` Christoph Hellwig
2005-01-29 18:10 ` John Richard Moser
2005-01-29 18:12 ` Rik van Riel
2005-01-29 18:16 ` Christoph Hellwig
2005-01-29 7:46 ` John Richard Moser
2005-01-27 18:40 ` Felipe Alfaro Solana
2005-01-27 22:31 ` Jirka Kosina
2005-01-28 5:58 ` Ingo Molnar
2005-01-28 19:02 ` David Lang
2005-01-28 7:33 ` Arjan van de Ven
2005-01-27 19:43 ` Julien TINNES
2005-01-28 0:10 ` H. Peter Anvin
2005-01-28 0:23 ` Roland Dreier
2005-01-28 1:06 ` H. Peter Anvin
2005-01-28 2:03 ` Horst von Brand
2005-01-28 8:45 ` Julien TINNES
2005-01-27 20:23 ` Christoph Hellwig
2005-01-27 20:27 ` Arjan van de Ven
2005-01-27 20:32 ` Christoph Hellwig
2005-01-27 20:35 ` Arjan van de Ven
2005-01-27 20:40 ` Rik van Riel
2005-01-27 20:42 ` Christoph Hellwig
2005-01-27 20:56 ` Arjan van de Ven
2005-01-27 21:13 ` Linus Torvalds
2005-01-27 10:13 ` Patch 5/6 randomize mmap addresses Arjan van de Ven
2005-01-27 10:14 ` Patch 6/6 default enable randomisation for -mm Arjan van de Ven
2005-01-27 11:45 ` Patch 0/6 virtual address space randomisation Julien TINNES
2005-01-27 11:57 ` Arjan van de Ven
2005-01-27 17:42 ` John Richard Moser
2005-01-27 19:34 ` Julien TINNES
2005-01-27 19:57 ` John Richard Moser
2005-01-27 20:13 ` Arjan van de Ven
2005-01-28 8:45 ` David Weinehall
-- strict thread matches above, loose matches on Subject: below --
2005-01-31 10:55 Patch 4/6 randomize the stack pointer linux
2005-01-31 17:28 ` John Richard Moser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41FBC200.9050404@comcast.net \
--to=nigelenki@comcast.net \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox