Re: why is text address constant with full randomization?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]

On 2015-09-21 10:31, 慕冬亮 wrote:
> 2015-09-15 17:05 GMT+08:00 yalin wang <yalin.wang2010@gmail.com>:
>>
>>> On Sep 15, 2015, at 16:36, 慕冬亮 <mudongliangabcd@gmail.com> 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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]