Founded in 2014 by Oliver Pinter and Shawn Webb, HardenedBSD is a security-enhanced fork of FreeBSD. The HardenedBSD Project is implementing many exploit mitigation and security technologies on top of FreeBSD. The project started with Address Space Layout Randomization (ASLR) as an initial focal point and is now implementing further exploit mitigation techniques.

Why Fork FreeBSD?

HardenedBSD forked the FreeBSD codebase for ease of development. Prior to HardenedBSD’s founding, Oliver and Shawn worked on separate repositories, occasionally causing collaboration issues. Unifying the codebases was a natural step in efficient, effective collaboration between the two individuals. More than three years have passed since the unification of the work and HardenedBSD is growing faster than ever.

HardenedBSD’s Goals

HardenedBSD aims to implement innovative exploit mitigation and security solutions for the FreeBSD community. Security is like an onion–it’s made up of layers. In order to be successful, attackers must peel back each layer. HardenedBSD takes a holistic approach to security by hardening the system and implementing exploit mitigation technologies. We will work with FreeBSD and any other FreeBSD-based project to include our innovations.

Who is HardenedBSD?

HardenedBSD’s core team consists of Oliver Pinter and Shawn Webb. If you’d like to know more about the team involved in HardenedBSD, please visit the Meet the Team page.The following projects are being implemented by the HardenedBSD team. Please note that documentation is actively being worked on.

  • PaX-Inspired Address Space Layout Randomization (ASLR)
    • ASLR serves as the base exploit mitigation technology upon which further mitigations are built. ASLR changes the memory layout such that if an attacker knows a program has a vulnerability, the attacker won’t know where the vulnerability lies in memory since the memory layout has been randomized. This makes life extremely difficult for the attacker. HardenedBSD’s implementation of ASLR is the strongest implemented in any of the BSDs.
  • PaX-Inspired SEGVGUARD
    • In some cases, ASLR can be defeated. Techniques known as ROP (and ROP’s variants) can defeat ASLR, given an information leakage vulnerability that leaks memory addresses. An attacker can generate a ROP payload on-the-fly using a technique called BROP. However, BROP generally takes a few tries to get right, causing the application to crash with each try. If the application being attacked is configured to respawn in case of crashes, an attacker can automate ROP payload generation. SEGVGUARD helps protect against this brute-force method of defeating ASLR by preventing the restart of applications who crash via a segmentation fault (SIGSEGV) multiple times within a given period.
  • PaX-inspired mprotect and pageexec hardening (aka, NOEXEC)
    • Memory allocations can have three permissions set: Read, Write, EXecute. An attacker will generally try to place his malicious code in a spot in memory that is both writable and executable. NOEXEC prevents the creation of memory allocations that have both the writable and execute permissions set. If an allocation is created as writable, it can never be marked as executable. If is created as executable, it can never be marked as writable. Most notable offenders of NOEXEC are applications with a Just-In-Time (JIT) compiler, like Firefox, Chromium, and Java.
  • procfs/linprocfs hardening
    • procfs can serve as an interesting attack vector. We hardened procfs and linprocfs to prevent attackers from controlling processes by manipulating key files in [lin]procfs. These files are generally used for debugging purposes. Attempts to write to these debugging files will generate an error.
  • secadm – HardenedBSD Security Administration
    • secadm is a tool specific to HardenedBSD that lets you toggle various exploit mitigation features on a per-application, per-jail basis. Like mentioned above, applications like Firefox and Chromium dislike NOEXEC and will crash or exhibit errors if NOEXEC is enabled for them. secadm can be used to disable NOEXEC for those applications. Similarly, if an application misbehaves with other exploit mitigation features, like ASLR, that feature can be turned off just for that application.Additionally, secadm includes a feature called Integriforce–file integrity enforcement. Integriforce allows a system administrator to ensure file integrity through hash enforcement–similar in concept to NetBSD’s Veriexec. Integriorce can be set in whitelisting mode, turning Integriforce into a verified application whitelisting tool.
  • Removal of older image activators (aka, executable file formats):
    • a.out image activator
    • gzip+a.out boot activator
    • SVR4 image activator
    • COFF image activator
    • IBCS2 image activator
  • Intel Supervisor Mode Access Prevention
  • arc4random
  • getentropy
  • mmap(MAP_32BIT) hardening
  • Boot hardening
  • Randomization of shared object loading order
  • Recursive support in setfacl(1)
  • Other hardening techniques
  • LibreSSL is the default crypto library in base.
  • OpenNTPD is the default NTP daemon in base.
  • PIE, RELRO, and BIND_NOW enabled for base
  • Hardening framework for ports, enabling PIE, RELRO, SafeStack, CFI, and BIND_NOW for the whole ports tree


Please enter your comment!
Please enter your name here