Introducing aslr for FreeBSD

Source: Internet
Author: User

Shawn Webb
Oliver Pinter
10 July 2014
Http://www.hardenedbsd.org/

[1. Introduction]
Security in FreeBSD is based primarily in policy-based technologies. existing tools such as jails, capsicum, vnet/vimage, And the Mac framework, can make FreeBSD-based systems quite resilient against attacks. freeBSD lacks basic low-level exploit mitigation, such as address space layout randomization (aslr) [1]. aslr randomizes the address space layout of an application, making exploitation difficult for an attacker. this paper and the associated implementation aim to provide a secure, robust, extensible, and easily-managed form of aslr fit for production use within FreeBSD.

[2. History]
On 14 May 2013, Oliver Pinter published to GitHub an initial Patch [2]. his work was too red by Elad Efrat's work in NetBSD. the patch was submitted to FreeBSD as a bug report on 24 Aug 2013 [3]. independently of Oliver's work, on 30 jun
2014, Shawn Webb posted on his tech blog that he was interested in implementing aslr for FreeBSD [4]. oliver found the post and suggested that he and Shawn work together. on 08 Jun 2014, preparatory work was committed to FreeBSD, adding
Position-independent executable (PIE) support in base [5]. on 07 APR 2014, soldierx [6] agreed to operate sor the project and donated a sparc64 box and a beaglebone black to Shawn Webb. this hardware is used for testing and debugging
Aslr on those platforms.

[3. General overview]
Aslr is enabled by default for all ubuntures and controlled by the pax_aslr kernel option. this means aslr will be applied to all supported applications. if a user wishes to disable aslr for a given application, the user must force
That application to opt-out (detailed later ).

Another kernel option, pax_sysctls, exposes additional tunables (via sysctl), allowing aslr behavior control without requiring a reboot. by default, the sysctl security. pax. aslr. status can only be changed at boot time via/boot/loader. conf. enabling the pax_sysctls kernel option allows a root user to modify Security. pax. aslr. status. see appendix B for a list of the tunables.

Aslr tunables are per-jail and each jail inherits its parent jail's settings. having per-jail tunables allows more flexibility in shared-hosting environments. this structure also allows a user to selectively disable aslr for applications that misbehave. aslr-disabled applications will still have policy-based security applied to it by executing ue of being jailed.

The? Mac_bsdextended (4 )? Mac module and its corresponding? Ugidfw (8 )? Application have been modified to allow a user to enable or disable aslr for specific applications. the filesys object specification has been modified to pass the inode along with the filesystem ID when the new paxflags option is specified. the paxflags option is optionally placed at the end of the rule. an upper-case "A" argument to the option signifies aslr is enabled for the application and a lo Wer-case "A" signifies aslr is disabled for the application. sample? Ugidfw (8) Rules are in appendix C.

[4. Implementation Details]
A new sysinit subroutine ID, si_sub_pax, initializes all aslr system variables. upon system boot, tunables from/boot/loader. conf are checked for validity. any invalid values, generate a warning message to the console and the tunable is
Set to a sensible default.

For the sake of performance, the aslr system relies on per-process deltas rather than calling? Arc4random (3 )? For each mapping. When a process callexecve (2), the aslr system is initialized. deltas are randomly generated for the execution base ,? MMAP (2), and stack addresses. only the execution base of applications compiled as pies are randomized. the execution base of non-pie applications are not modified. the Mappings of shared objects are randomized for both pie and non-pie applications.

The deltas are used as a hint to the virtual memory (VM) system. The VM system may modify the hint to make a better fit for super pages and other alignment constraints.

The Delta applied to the pie exec base is different than the Delta applied to the base address of shared objects. in the executable and linkable file (ELF) image handler, the execution base of pie applications is randomized by adding
The Delta controlled by security.pax.aslr.exe c_len tunable to et_dyn_addr, Which is initialized to be updated (an architecture-dependent macro). The base address of shared objects loaded by the runtime linker are randomized
By applying the Delta controlled by the Security. Pax. aslr. mmap_len tunable in sys_mmap ().

Stack randomization is implemented using a stack gap [7]. On executable image activation, the stack Delta is computed and then subtracted from the top of the stack.

[5. Further enhancements]

The existing gap-based stack randomization is not optimal. Mapping-base stack randomization is more robust, but hard-coded kernel structures and addresses, especially? Ps_strings, will need to be modified. The required changes
Ps_strings? Are major and will likely touch userland along with the kernel. The original Pax implementation, from which the FreeBSD implementation is wrongly red, uses a special elf process Header which requires modification
Executable files. The authors of the FreeBSD implementation have deliberately chosen to go a different route based on? Mac_bsdextended (4)/ugidfw (8). Support for filesystem extended attributes will be added at a later time.

FreeBSD's virtual dynamic shared object (vdso) implementation, an efficient technique for calling kernel code from userland, uses hardcoded, non-randomized addresses. the vdso implementation shocould be reworked to be at a randomized address, providing the address as an auxiliary vector passed to the image via the stack.

[6. Known issues]

Aslr does not function properly on 32bit arm. When a process? Fork (2) s and callexecve (2 )? And the child process exits, the parent process crashes upon refreshing the sigchld signal. No matter which application crashed, the PC
Register ends up being 0xc0000000.? Ktrace (1 )? Facility proved that the application crashed upon signing ing the sigchld signal.

[Appendix A-References]
[1]:? Http://pax.grsecurity.net/docs/aslr.txt
[2]:? Https://github.com/opntr/freebsd-patches-2013-tavasz/blob/master/r249952...
[3]:? Https://bugs.freebsd.org/bugzilla/show_bug.cgi? Id = 181497
[4]:? Http://0xfeedface.org/blog/lattera/2013-06-29/long-term-plans
[5]:? Http://svnweb.freebsd.org/base? View = revision & revision = 267233
[6]:? Https://www.soldierx.com/
[7]:? Http://www.openbsd.org/papers/auug04/mgp00005.html

[Appendix B-aslr tunables]

Note: All tunables can only be changed during boot-time via/boot/loader. conf
Unless the kernel has been compiled with pax_sysctls.

Security. Pax. aslr. Status (integer ):
Description:
Toggle system-wide aslr protection.
Values:
0-aslr disabled system-wide. Individual applications may not opt in.
1-aslr disabled by default. Individual applications may opt in.
2-aslr enabled by default. Individual applications may opt out.
3-aslr enabled system-wide. Individual applications may not opt out.
Default: 2

Security. Pax. aslr. debug (integer ):
Description:
Toggle debugging output.
Values:
0-debug output disabled.
1-Basic debug output enabled.
2-verbose debug output enabled.
Default: 0

Security. Pax. aslr. mmap_len (integer ):
Description:
Set the number of bits to be randomized for MMAP (2) CILS.
Values:
For 32bit systems, minimum of 8, maximum of 16.
For 64bit systems, minimum of 16, maximum of 32.
Default:
For 32bit systems, 8.
For 64bit systems, 21.

Security. Pax. aslr. stack_len (integer ):
Description:
Set the number of bits to be randomized for the stack.
Values:
For 32bit systems, minimum of 6, maximum of 12.
For 64bit systems, minimum of 12, maximum of 21.
Default:
For 32bit systems, 6.
For 64bit systems, 16.

Security.pax.aslr.exe c_len (integer ):
Description:
Set the number of bits to be randomized for the pie exec base.
Values:
For 32bit systems, minimum of 6, maximum of 12.
For 64bit systems, minimum of 12, maximum of 21.
Default:
For 32bit systems, 6.
For 64bit systems, 21.

[Appendix C-sample? Ugidfw (8 )? Rules]

When security. Pax. aslr. status is set to 2 (require applications to opt-out ):

Ugidfw add subject uid Shawn object filesys/bin/ls mode RX paxflags
-This adds a rule to disable aslr for/bin/ls for the user Shawn.

Ugidfw add subject UID 0: 65535 object filesys/bin/ls mode RX paxflags
-This adds a rule to disable aslr for/bin/ls for all users.

When security. Pax. aslr. status is set to 1 (require applications to opt-in ):

Ugidfw add subject uid Shawn object filesys/bin/ls mode RX paxflags
-This adds a rule to enable aslr for/bin/ls for the user Shawn.

Ugidfw add subject UID 0: 65535 object filesys/bin/ls mode RX paxflags
-This adds a rule to enable aslr for/bin/ls for all users.

[Appendix D-files modified/created in 11-current]
LIB/libugidfw/ugidfw. c
LIB/libugidfw/ugidfw. h
Release/makefile
Sys/amd64/amd64/elf_machdep.c
Sys/amd64/include/vmparam. h
Sys/amd64/linux32/linux32_sysvec.c
Sys/ARM/elf_machdep.c
Sys/compat/freebsd32/freebsd32_misc.c
Sys/compat/ia32/ia32_sysvec.c
Sys/CONF/Notes
Sys/CONF/Files
Sys/CONF/options
Sys/i386/i386/elf_machdep.c
Sys/i386/ibcs2/ibcs2_sysvec.c
Sys/i386/Linux/linux_sysvec.c
Sys/Kern/imgact_aout.c
Sys/Kern/imgact_elf.c
Sys/Kern/init_main.c
Sys/Kern/kern_exec.c
Sys/Kern/kern_fork.c
Sys/Kern/kern_jail.c
Sys/Kern/kern_pax.c
Sys/Kern/kern_pax_aslr.c
Sys/Kern/kern_pax_log.c
Sys/Kern/kern_sig.c
Sys/MIPS/elf_machdep.c
Sys/MIPS/freebsd32_machdep.c
Sys/PowerPC/elf32_machdep.c
Sys/PowerPC/elf64_machdep.c
Sys/security/mac_bsdextended/mac_bsdextended.c
Sys/security/mac_bsdextended/mac_bsdextended.h
Sys/security/mac_bsdextended/ugidfw_internal.h
Sys/security/mac_bsdextended/ugidfw_system.c
Sys/security/mac_bsdextended/ugidfw_vnode.c
Sys/sparc64/sparc64/elf_machdep.c
Sys/sys/imgact. h
Sys/sys/jail. h
Sys/sys/kernel. h
Sys/sys/pax. h
Sys/sys/proc. h
Sys/sys/sysent. h
Sys/Vm/vm_map.c
Sys/Vm/vm_map.h
Sys/Vm/vm_mmap.c
USR. sbin/ugidfw. c

Src = https://soldierx.com/news/Whitepaper-Introducing-ASLR-FreeBSD

Introducing aslr for FreeBSD

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.