paxtest strcpy() returns "bad luck..."

[cpruefer]

if i do a "paxtest kiddie" or "paxtest blackhat"
on i386 (amd athlon-xp)

i get result:

strcpy() bad luck, try different compiler settings

seems like paxtest compiled wrong?

should this test work to ensure pax working correctly?

[PaX Team]

if i do a "paxtest kiddie" or "paxtest blackhat"
on i386 (amd athlon-xp)

i get result:

strcpy() bad luck, try different compiler settings

seems like paxtest compiled wrong?

what paxtest version is this? i think the latest from the PaX test directory shouldn't produce this on i386.

should this test work to ensure pax working correctly?

the return-to-libc tests are supposed to fail, so you shouldn't lose any sleep over them anyway.

[cpruefer]

what paxtest version is this? i think the latest from the PaX test directory shouldn't produce this on i386.

its 0.9.6 (gentoo 2006.1 hardened emerged)...
i will try compile the lastest from source and retest...

[cpruefer]

with paxtest-0.9.7-pre4

EVERYTHING is FINE!!!

now i get a "stack smashing detected" on both strcpy, memcpy tests...

paxteam, you did produce a very satisfied "customer"
when it ever should happen that i have money, be sure to receive a donation...

just one remark: with makefile for gentoo building breaks

make generic works...

[PaX Team]

with paxtest-0.9.7-pre4

EVERYTHING is FINE!!!

now i get a "stack smashing detected" on both strcpy, memcpy tests...

that's actually a bug in the makefile, ssp is supposed to be disabled and the tests should show vulnerability (remember that paxtest tests, well, PaX, not other solutions and we have no deterministic protection against ret2libc attacks yet).

just one remark: with makefile for gentoo building breaks

make generic works...

the makefiles are sort of messy, fixing them is on the ever-growing todo list...