paxtest memcpy() returns vulnerable

[cpruefer]

hi @ pax forum!

im a newbie to pax, so please dont kill me...

i have gentoo hardened kernel 2.6.20 on i686 amd duron mobile...
PIE+SSP enabled (gcc 3.4.6)

when i run paxtest (kiddie or blackhat) i get

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

other vulnerability checks are ok...


my pax kernel config is:

CONFIG_PAX_EI=y

CONFIG_PAX_PT_FLAGS=y
CONFIG_PAX_HAVE_ACL_FLAGS=y

CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_SEGMEXEC=y

CONFIG_PAX_DEFAULT_SEGMEXEC=y

CONFIG_PAX_MPROTECT=y
CONFIG_PAX_NOELFRELOCS=y
CONFIG_PAX_KERNEXEC=y

CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_MEMORY_UDEREF=y

what am i doing wrong? searched forum but did not find an answer...

[cpruefer]

as for what to worry about, any failing paxtest result means a potential exploit technique that works on your system, at least as far as PaX is concerned. what you can do about them as a gentoo hardened user is not a lot, you're already using PIE and SSP, the two techniques that provide main executable randomization and mitigate some stack corruption bugs.

another question about scenario:

SERVER:
has infected sshd, attacker is able to infect arbitrary code into tcp/ip stream...

CLIENT:
secured with PaX, PIE, SSP

QUESTION:
with ret2libc attack,
if attacker can crash the local running ssh client,

im not too deep into this subject, but
also if the libc.so is located randomly into memory at ssh client start,
couldnt the attacker now easily call any libc function
"if he knows how the local libc.so is compiled"?
and other shared object functions, because its allocated allready into memory?

[cpruefer]

im not too deep into this subject, but
also if the libc.so is located randomly into memory at ssh client start,
couldnt the attacker now easily call any libc function
"if he knows how the local libc.so is compiled"?
and other shared object functions, because its allocated allready into memory?

i think i am wrong!!!

just a little question about scenario:

BINARY resides @ RANDOM_ADDRESS at execution
LIBRARIES get loaded into memory @ RANDOM_ADDRESS

first protection: stack smashing protector
second protection: random memory loaded libraries

so somehow if attacker could get around stack smashing protection,
the only possibility to execute code is to guess addresses in the loaded LIBRARIES with NOP generating?

but in the loaded BINARY the attacker could execute functions at addresses when he knows the exact compiler/system settings of your system?!? so he can calculate the right offsets where the functions reside in memory?!? am i right?

thanx for your effort...

[PaX Team]

BINARY resides @ RANDOM_ADDRESS at execution
LIBRARIES get loaded into memory @ RANDOM_ADDRESS

first protection: stack smashing protector
second protection: random memory loaded libraries

so somehow if attacker could get around stack smashing protection,
the only possibility to execute code is to guess addresses in the loaded LIBRARIES with NOP generating?

but in the loaded BINARY the attacker could execute functions at addresses when he knows the exact compiler/system settings of your system?!? so he can calculate the right offsets where the functions reside in memory?!? am i right?

if the binary is loaded at a random address, then the same considerations apply to it as the libraries . also, you're mixing up something with NOP generation, runtime code generation is not allowed under PaX, nor is it needed to guess addresses in already existing code for that matter.

[Alexei.Sheplyakov]

another question about scenario:

SERVER:
has infected sshd, attacker is able to infect arbitrary code into
tcp/ip stream...

CLIENT:
secured with PaX, PIE, SSP

QUESTION:
with ret2libc attack,

I think there are a lot of other things to worry about in this case.
The cracker is able to monitor the keyboard input, steal passwords,
passphrases, authentication credentials (such as Kerberos tickets),
etc. WITHOUT attacking the client.

[Kp]

I think there are a lot of other things to worry about in this case.
The cracker is able to monitor the keyboard input, steal passwords,
passphrases, authentication credentials (such as Kerberos tickets),
etc. WITHOUT attacking the client.

Yes, those things are all worth worrying about, but it is still a valid question. For instance, if the server was a honeypot that you expected to get compromised, you do not want the compromise to spread to real machines when you connect to the honeypot to monitor its progress.

Similar concerns apply if you are connecting to a machine for which you do not trust the administrator. In such a case, you know not to expect confidentiality of anything you send to the peer, but you still want your local account and its files to be free from compromise / snooping.