Re: Patch 4/6 randomize the stack pointer

[John Richard Moser <nigelenki@comcast.net>]

-----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-----
> 
> 
>>These are the only places mprotect() is mentioned; a visual scan
>>confirms no trickery:
>>
>>        if( fork() == 0 ) {
>>                /* Perform a dirty (but not unrealistic) trick to circumvent
>>                 * the kernel protection.
>>                 */
>>                if( paxtest_mode == 1 ) {
>>                        pthread_t thread;
>>                        pthread_create(&thread, NULL, test_thread, dummy);
>>                        doit();
>>                        pthread_kill(thread, SIGTERM);
>>                } else {
> 
> 
>>So, there you have it.  These tests do not intentionally kill
>>exec-shield based on its known issue with tracking the upper limit of
>>the code segment.
> 
> 
> 
> here they do.
> dummy is a local NESTED function, which causes the stack to *correctly*
> be marked executable, due to the need of trampolines. 
> That disables execshield for any tests that use dummy.o, which most of
> them are.
> 

Only in "Blackhat" mode.  I ran in Kiddie and Blackhat mode, and my
second batch of tests (tests.txt, my errata) was run after execstack -c.

> 

root@iceslab:/mnt/redhat/root/paxtest-0.9.6 # strace ./execstack 2>&1 |
grep mprotect
mprotect(0x20822000, 4096, PROT_NONE)   = 0
root@iceslab:/mnt/redhat/root/paxtest-0.9.6 # strace ./execstack 2>&1 |
grep EXEC
old_mmap(NULL, 64996, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x265d9000
old_mmap(NULL, 1232332, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x265e9000
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x26716000

I killed the fork() line and straced it.
0x26716000 is only ~600 megs up,  I find my stack at ~1.5G under
segmexec, I'd guess it'd be at ~3G under normal things like execshield.
 You know what *looks*

getstack1:  0xfefcead7
getstack1:  0xfefe9947
getstack1:  0xfeedd4f7
getstack1:  0xfefe6e37
getstack1:  0xfee412b7
getstack1:  0xfee71737

Yeah it's pretty high under exec shield.

none of these are doing ANYTHING weird (grepping for EXEC and scanning
for PROT_EXEC and related addresses), aside from the normal mapping of
libraries by the system, which is probably what's killing Exec Shield's
anonymous mapping, heap, data, bss, library data, library bss. . .

To put it bluntly, you're wrong.  The tests are valid.

- --
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+8DuhDd4aOud5P8RAscYAKCErG3KB5M9gMwZ1BRqTDBKyYYLrACfcYeb
0ptJYTE+uUx0QYSHmKXWlsA=
=PL8+
-----END PGP SIGNATURE-----