lkml.org 
[lkml]   [2015]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: why is text address constant with full randomization?
From
Date
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).

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-09-21 21:21    [W:0.133 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site