Re: why is text address constant with full randomization?

From: Austin S Hemmelgarn
Date: Mon Sep 21 2015 - 14:59:36 EST

On 2015-09-21 10:31, æåä wrote:
2015-09-15 17:05 GMT+08:00 yalin wang <yalin.wang2010@xxxxxxxxx>:

On Sep 15, 2015, at 16:36, æåä <mudongliangabcd@xxxxxxxxx> wrote:

First, my linux kernel is Linux 114-212-83-136 4.1.0-2-amd64.
Second, I copy /bin/cat in system to mycat , and see the address space
layout below.

mdl@114-212-83-136:~$ ./mycat /proc/self/maps
00400000-0040c000 r-xp 00000000 08:03 1046776
/home/mdl/mycat
0060b000-0060c000 r--p 0000b000 08:03 1046776
/home/mdl/mycat
0060c000-0060d000 rw-p 0000c000 08:03 1046776
/home/mdl/mycat
01da7000-01dc8000 rw-p 00000000 00:00 0
[heap]
......

The starting address of executable image is constant with my aslr
configuration 2 (full randomization).
I think text segment should be inconstant to defeat the attack like
reusing text code!
Is it related to fixing offset2lib attack?
Thanks for any help!
- mudongliang

your mycat elf is executable elf file,
it is not possible to random the .text section address,
only relocatable elf file can be random,
you should build your elf with gcc -fPIC to make it relocatable .
So this means Debian(my computer) system does not compile its system
elf file with -fPIC in default.
With fixed text address, it's easy to be attacked.
Why there are many distributions which not compile their system elf file in PIC?
And in the real word, how do servers protect themselves from being
attacked in this way?
In general, most distributions don't compile executables with -fPIC, only libraries (this is, however, one of the main reasons I use Hardened Gentoo on most of my systems, they compile everything with -fPIC and SSP by default). Many of the types of attacks that ASLR and PIC are supposed to protect against are primarily targeted at libraries, so this makes at least some sense. Part of it may also be that PIC is notoriously slow on at least 32-bit x86 processors (which are _really_ starved for registers already), and still often slower on average than non-PIC code on 64-bit x86 processors as well. On top of that, stuff with inline assembly code tends to break when built with -fPIC unless it's been specially designed for it.

The thing is though, you shouldn't be depending on just ASLR and PIC for security, they should be one of many layers of security for a well secured system. The first should be good firewall policy, and the second should well audited and up-to-date network server code. Beyond that layer comes stuff like chroot and other forms of sandboxing or MAC layers (like SELinux).

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature