paxtest results and RANDEXEC

[grunthus]

Hi, I have a gentoo box with 2.6.14-hardened-r5 and paxtest-0.9.6 installed.
Paxtest produces the following output:

Code: Select all

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 17 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 23 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 15 bits (guessed)
Shared library randomisation test        : 17 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Killed
Executable shared library data           : Killed

I've read that strcpy and memcpy are handled via PIE binaries, which I have, so hopefully those first two vulnerabilities are nothing to worry about.

However I can't understand the RANDEXEC vulnerabilities since, reading other posts it seems RANDEXEC was removed from PaX? Certainly I can't see any kernel symbols corresponding to RANDEXEC. Should I worry?

Lastly, is the ET_EXEC 'no randomisation' something to worry about too?

I've been through the docs and forums a number of times over the last three days, so I hope I haven't missed the obvious. (I probably have!!)

Thanks

Chris

Excerpt from .config follows:

Code: Select all

CONFIG_PAX=y

#
# PaX Control
#
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_NO_ACL_FLAGS=y
# CONFIG_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_PAX_HOOK_ACL_FLAGS is not set

#
# Non-executable pages
#
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_SEGMEXEC=y
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set
CONFIG_PAX_DEFAULT_SEGMEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_NOELFRELOCS is not set
# CONFIG_PAX_KERNEXEC is not set

#
# Address Space Layout Randomization
#
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_NOVSYSCALL=y

#
# Grsecurity
#
CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MEDIUM is not set
# CONFIG_GRKERNSEC_HIGH is not set
CONFIG_GRKERNSEC_CUSTOM=y

#
# Address Space Protection
#
# CONFIG_GRKERNSEC_KMEM is not set
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y
# CONFIG_GRKERNSEC_BRUTE is not set
CONFIG_GRKERNSEC_HIDESYM=y
#
# Role Based Access Control Options
#
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=10
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
# CONFIG_GRKERNSEC_EXECLOG is not set
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
# CONFIG_GRKERNSEC_AUDIT_CHDIR is not set
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_AUDIT_IPC=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
# CONFIG_GRKERNSEC_AUDIT_TEXTREL is not set

#
# Executable Protections
#
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_SHM=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
# CONFIG_GRKERNSEC_TPE_INVERT is not set
CONFIG_GRKERNSEC_TPE_GID=100


[Hue-Bond]

Code: Select all

Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable

I've read that strcpy and memcpy are handled via PIE binaries, which I have, so hopefully those first two vulnerabilities are nothing to worry about.

I was about to make a post about precisely this very issue . My system is a standard gentoo hardened kernel with some minor modifications to the console and keyboard drivers. Since I'm using hardened gentoo, the majority of my executables are of the ET_DYN kind. Thus I can get advantage of the PAX_RANDMMAP feature. But:

Code: Select all

# file /usr/lib/paxtest/rettofunc*
/usr/lib/paxtest/rettofunc1:  ELF 32-bit LSB executable, Intel 80386 [...]
/usr/lib/paxtest/rettofunc1x: ELF 32-bit LSB executable, Intel 80386 [...]
/usr/lib/paxtest/rettofunc2:  ELF 32-bit LSB executable, Intel 80386 [...]
/usr/lib/paxtest/rettofunc2x: ELF 32-bit LSB executable, Intel 80386 [...]

This tests are executables, not shared objects (I assume there's a good reason for this). Nevertheless I tried to compile that programs without the '-nopie' parameter and saw that they're also vulnerable. Doing a 'paxctl -X' on them (PIE ones) does not activate the flag, I think that's because that flag only applies to executables. This puzzles me. I think they should be killed since they don't know the exact address to return to (needless to say, I don't know the details of that kind of attack). I don't know how to kill them.

However I can't understand the RANDEXEC vulnerabilities since, reading other posts it seems RANDEXEC was removed from PaX?

Not surprinsingly to me. PaX provided two ways of randomizing the executable's base address: RANDEXEC and RANDMMAP. The former is slow and prone to false positives while the latter does not have this drawbacks but only works on ET_DYN objects. That's why we all want to compile our programs with a hardened toolchain (gcc + binutils + libc) that takes care of this detail for us.

Lastly, is the ET_EXEC 'no randomisation' something to worry about too?

Dunno. I'd rather try to purge any ET_EXEC file from the system.

[PaX Team]

I've read that strcpy and memcpy are handled via PIE binaries, which I have, so hopefully those first two vulnerabilities are nothing to worry about.

However I can't understand the RANDEXEC vulnerabilities since, reading other posts it seems RANDEXEC was removed from PaX? Certainly I can't see any kernel symbols corresponding to RANDEXEC. Should I worry?

Lastly, is the ET_EXEC 'no randomisation' something to worry about too?

you're mixing up something here, the strcpy/memcpy tests demonstrate the so called return-to-libc attack which in general works against both PIEs and normal executables as well.

protecting against this kind of attack in general is hard, but certain subtypes can be thwarted to an extent by randomization, stack layout changes (SSP and the like), etc. the general solution will need userland changes as outlined in the PaX future doc, but in the meantime and in the interest of not giving anyone a false sense of security, we included these tests and they are meant to fail.

now historically as a proof of concept PaX had RANDEXEC which among others could be used to detect a kind of ret2libc attack, so we had a test for that just to show that It Works (tm), but it was never meant to be used in production for reasons discussed numerous times already. some time last year i decided to remove it for good because it became quite a burden to forward port in the ever changing 'stable' 2.6 series (the inherent complexity of RANDEXEC was also the reason for the unfortunate bug announced a year ago, another nail in its coffin).

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.

[grunthus]

Right. The pieces are falling into place - thank you both for your input.