• LOGIN
  • No products in the cart.

HardenedBSD Proactive Security Project by David Carlier

Oliver Pinter and Shawn Webb brought to life a security-centric distribution of FreeBSD called HardenedBSD. HardenedBSD aims to continuously implement kernel and userland hardening features, such as Address Space Layout Randomization (ASLR), mprotect hardening, Position Independent Executable (PIE) support, and PTrace hardening, among other features.


The HardenedBSD project started due to the complexity involved in implementing ASLR. I recently joined the HardenedBSD development team, implementing PTrace hardening, arc4random enhancements, getentropy() support, and other userland hardening features. In this article, I’d like to detail ASLR. Let’s start with this simple piece of sam- ple C++ code (compiled with -fPIE -pie): Listing 1.Screen Shot 2016-04-22 at 14.03.09

Executing this sample application multiple times when ASLR is enabled produces this output:

address of da 0x9c2406058 address of da 0x8b8806058 address of da 0x9d7806058

Since the memory layout of the application is randomized, an attacker will have a hard time determining the location in memory where a given vulnerability might reside. Via procstat, you can also see the start address of the concerned binary, for example:

procstat -v <pid of the example app> ... First launch 

PID START END ... PATH

 54318 0x5afe5000 ... Second launch 55773 0x21282000 ...

0x5afe6000 0x21283000

vn /tmp/datest vn /tmp/datest

Executing this sample application multiple times when ASLR is disabled produces this output:

address of da 0x801c06058 address of da 0x801c06058 address of da 0x801c06058

procstat checking

... First launch
PID START END ... PATH

68978 0x400000 ... Second launch 84429 0x400000

0x401000 vn /tmp/datest

0x401000 vn /tmp/datest

Note that while ASLR makes life a little bit harder for an attacker, it is not the end-all-be-all of exploit mitigation techniques. Exploit techniques like Blind ROP (BROP) can defeat ASLR. When ASLR is combined with multi- ple exploit mitigation techniques, security is greatly enhanced and ASLR-defeating exploit payloads can be rendered inadequate.

Conclusions

ASLR is enabled by default for all architectures and controlled by the PAX_ASLR kernel option. This means that 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 optout (detailed later).

Another kernel option, PAX_SYSCTLS, exposes addi- tional 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 them by virtue of being jailed.

The mac_bsdextended(4) MAC module and its corresponding ugidfw(8) application have been modified to allow a user to enable experienceor 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 uppercase “A” argument to the option signifies ASLR is enabled for the application and a lowercase “a” signifies ASLR is disabled for the application. Sample ugidfw(8) rules are in Appendix C. This feature is only implemented in the HardenedBSD project and likely won’t be upstreamed to FreeBSD without further review and sign-off from certain key FreeBSD developers.

We are working on upstreaming our ASLR implementation with the FreeBSD project. Sean Bruno is the developer on the FreeBSD side who is sponsoring the commit.


About the Author:

DAVID CARLIER

David Carlier has been working as a software developer since 2001. He used FreeBSD for more than 10 years and starting from this year, he be- came involved with the HardenedBSD project and performed serious developments on FreeBSD. He worked for a mobile product company that provides C++ APIs for two years in Ireland. From this experience, he became completely inspired to develop on FreeBSD.

Article comes from BSD Mag VOL 08, No 10/10.2014 (63)

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of
© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013