grsecurity forums

Hello,

I have ET_EXEC binary on my system (gentoo 2004.2), for example:

# file /usr/bin/iconv
/usr/bin/iconv: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped

# scanelf /usr/bin/ | grep iconv
PeMRxS ET_EXEC /usr/bin//iconv

I have also kernel 2.4.27 with grsec-2.0.1, with option Address Space Protection -> Randomize ET_EXEC base turned OFF.

So why I have address randomization on this binary ?

# ldd /usr/bin/iconv
libc.so.6 => /lib/libc.so.6 (0x2ec01000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2ebeb000)
# ldd /usr/bin/iconv
libc.so.6 => /lib/libc.so.6 (0x2c013000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2bffd000)


I have also the second question:
Is really important to have ALL binaries on the system compiled as ET_DYN ? I have few non-important ( no-suids and no-daemons ) programs still compiled as ET_EXEC ... hardened-gentoo and adamantix are not fully ET_DYN-compiled distros .. Is it worth fighting ?


ps. Sorry for my very bad English.

best regards,
Konrad.

voices wrote:# scanelf /usr/bin/ | grep iconv
PeMRxS ET_EXEC /usr/bin//iconv

I have also kernel 2.4.27 with grsec-2.0.1, with option Address Space Protection -> Randomize ET_EXEC base turned OFF.

So why I have address randomization on this binary ?

RANDEXEC (the above config option) is different from RANDMMAP (that among others causes the library load address randomization).

Is really important to have ALL binaries on the system compiled as ET_DYN ? I have few non-important ( no-suids and no-daemons ) programs still compiled as ET_EXEC ... hardened-gentoo and adamantix are not fully ET_DYN-compiled distros .. Is it worth fighting ?

the sole benefit of PIEs (position independent executables, the 'official' name of ET_DYN executables these days) is that they're 'naturally' randomized, so their worth is a function of how important their randomization is to you. personally i don't put much faith into randomization approaches, they're just cheap enough to accomplish but they don't solve fundamental problems, only make them harder to exploit. whether such probabilistic assurance is worth your time/effort/etc is a question only you can answer. from a practical point of view you'd be best off by having all apps that process untrusted (potentially malicious) input as PIEs, that means all network facing daemons and certain client apps like web browsers, mail clients, etc.

PaX Team wrote:the sole benefit of PIEs (position independent executables, the 'official' name of ET_DYN executables these days) is that they're 'naturally' randomized, so their worth is a function of how important their randomization is to you. personally i don't put much faith into randomization approaches, they're just cheap enough to accomplish but they don't solve fundamental problems, only make them harder to exploit. whether such probabilistic assurance is worth your time/effort/etc is a question only you can answer. from a practical point of view you'd be best off by having all apps that process untrusted (potentially malicious) input as PIEs, that means all network facing daemons and certain client apps like web browsers, mail clients, etc.

So, as far as I understand it doesn't matter from the point of view of security If ALL executables are ET_DYN, it's absolutely enought to have only attack vulnerable programs ( daemons, suids, net-clients) compiled this way ? Having, for example modutils, lilo or vim compiled as ET_DYN doesn't improve security in any way ?

thanks for answer,

best regards,
Konrad

An app that nobody tries to exploit doesn't need to be ET_DYN, no. But the limits of what is exploitable are hard to determine. If your toolchain supports it it's easier to just build everything that way rather than picking and choosing.