Messages in this thread | | | Subject | Re: why is text address constant with full randomization? | From | Austin S Hemmelgarn <> | Date | Mon, 21 Sep 2015 14:59:27 -0400 |
| |
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] | |