Hardened BSD

HardenedBSD – Proactive Security Project

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

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 sample C++ code (compiled with -fPIE -pie):

Listing 1. Sample C++ code

#include <mtld/devatlas.h>

#include <cstdio>

#include <memory>

using namespace std;

using namespace Mobi::Mtld;

int

main(int argc, char *argv[])

{

…

unique_ptr<Da::DeviceAtlas> da(new Da::DeviceAtlas());

da->loadDataFromFile(argv[1]);

…

printf(“addr of da %p\n”, da.get());

…

return (0);

}

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 0x5afe6000 vn /tmp/datest

… Second launch

55773 0x21282000 0x21283000 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 0x401000 vn /tmp/datest

… Second launch

84429 0x400000 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 multiple 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 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 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 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 lower-case “a” signifies ASLR is disabled for the application. Sample ugidfw(8) rules are in Appendix C. This feature is only implemented in the HardenedBSD[8] 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 has been working as a software developer since 2001. He used FreeBSD for more than 10 years and starting from this year, he became 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.