PIE, RELRO, and BIND_NOW for ports

Submitted by Shawn Webb on

We have now enabled PIE, RELRO, and BIND_NOW for the whole ports tree. This is a huge leap forwards for HardenedBSD. We now have all of base compiled with PIE + RELRO + BIND_NOW, and now a good portion of ports as well. A good portion of ports should work with PIE, RELRO, and BIND_NOW. In those cases where ports won't compile or run with PIE, check for NOPIE. In those cases where ports won't compile or run with RELRO + BIND_NOW, check for NORELRO. Please note that some ports ignore custom CFLAGS/CXXFLAGS/LDFLAGS and as such will not compile with PIE + RELRO + BIND_NOW enabled.

PIE and RELRO + BIND_NOW are disabled by default for ports that have either kmod or fortran USES flags. Kernel modules cannot be compiled with PIE, RELRO, and BIND_NOW. More research is needed for the fortran ports.

If PIE is disabled by default for a port, but the port maintainer wants to force PIE to be enabled by default, the port maintainer can set EXPLICIT_PIE. The same logic applies for RELRO + BIND_NOW, but with EXPLICIT_RELRO.

A follow-up commit has been made to explicitly disable PIE or RELRO + BIND_NOW for a number of ports. Out of roughly 26,000 ports, only around 400 failed to compile due to PIE or RELRO + BIND_NOW.

Given that there's over 26,100 ports in the tree, HardenedBSD will need to rely on its ever-growing community for runtime testing. Simply compiling an application does not mean that the application will run successfully. As an example, xorg will compile fine with RELRO + BIND_NOW, but due to how it integrates with modules during runtime, it will break. xorg still runs fine with PIE, however.

If you experience issues with a port or package, please file a bug report here.

Vulnerability Update: libarchive

Submitted by Shawn Webb on

Around three months ago, a post was published (mirror) on GitHub's Gist service. In the report, multiple vulnerabilities against portsnap, freebsd-update, bspatch, and libarchive were detailed. To this date, FreeBSD has been silent on official mailing lists. However, Allan Jude talked very briefly about it on BSDNow. FreeBSD is still vulnerable to the portsnap, freebsd-update, bspatch, and libarchive vulnerabilities.

Shortly after HardenedBSD was made aware of the vulnerabilities, Shawn Webb researched how HardenedBSD was affected. Since HardenedBSD has disabled portsnap and freebsd-update by default, HardenedBSD is not vulnerable to the portsnap and freebsd-update vulnerabilities. HardenedBSD does not have supporting infrastructure for portsnap or freebsd-update. The report detailed four vulnerabilities in libarchive, two of which were fixed with FreeBSD's import of libarchive 3.2.1. The other two were fixed by HardenedBSD commits acc5eaecbe4970cfb96d9549fe7dc8ceb4676557 and 6a6ac73ae630927b2dd996df3cd85c8c612c459c. The second commit has potential for fall-out, so additional testing is being performed.

For binary updates to base, HardenedBSD relies on a tool called hbsd-update, which is enabled by default in base. hbsd-update was affected. hbsd-update updates come in a single tarball that contains multiple file within it. Prior to the series of commits fixing hbsd-update, the outer tarball was not validated prior to extraction. Only the inner files were validated by enforcing digital signatures. The libarchive vulnerabilities could allow a malicious third-party to distribute update archives that could place arbitrary files on the filesystem. To address this issue, the hash of the current hbsd-update is published as part of the DNS TXT record. HardenedBSD's DNS entries are signed with DNSSEC, which hbsd-update now verifies. By utilizing DNSSEC, hbsd-update can ensure that not only the version information is valid, but also the hash of the update archive--effectively turning the DNS TXT record into a digital signature for the outer file. Those who publish their own binary updates using hbsd-update-build are advised to do the same.

Due to the new DNSSEC validation feature in hbsd-update, the unbound-host application has been wired into the base build. FreeBSD includes the code for unbound-host; however, it is not wired into the build. Additionally, we now install the DNSSEC root key 257 as part of the hbsd-update trust store. Since DNSSEC key material is routinely rotated, we will maintain the DNSSEC root key pinning in the trust store long-term.

Once FreeBSD has fixed the issues surrounding libarchive, we at HardenedBSD will evaluate using their fixes. We hope FreeBSD will communicate with their community soon regarding the already-public vulnerabilities.

LibreSSL Package Repo

Submitted by Shawn Webb on

We are pleased to announce the availability of the LibreSSL package repo for 11-CURRENT/amd64. This repo is based off of the LibreSSL-in-base branch (hardened/current/master-libressl) that Bernard Spil has been working on. Going forward, along with providing binary updates for that branch via hbsd-update(8), we will also provide binary packages. We will also provide binary packages soon for the LibreSSL 10-STABLE branch (hardened/10-stable/master-libressl). Having both the feature branches along with package repos will allow us to investigate making LibreSSL the standard in HardenedBSD.

We would like to thank Bernard Spil for his continuous hard work. We're glad to have him on the team. Thanks to him, HardenedBSD is the first downstream FreeBSD project to have both LibreSSL in base along with a package repo that matches.

hbsd-update now installing Integriforce ruleset

Submitted by Shawn Webb on

We are excited to announce the ability to easily utilize Integriforce with base. From now on, hbsd-update(8) will install a full Integriforce ruleset as /etc/secadm.d/base.integriforce.rules for base. If you include this file in your normal secadm.rules(5) ruleset, you will get full integrity enforcement on all executable files in base. If you include the applications from ports/packages in your secadm.rules(5) file, you can turn on whitelisting mode, in which case, all executable files that aren't protected by Integriforce will be denied execution. If you only utilize applications from base, you can turn on whitelisting mode and get the same results.

Using the Integriforce ruleset is entirely optional, but highly recommended.

An example secadm.rules file might look something like this:

secadm {
    pax {
        path: "/usr/local/lib/firefox/firefox",
        pageexec: false,
        mprotect: false
    }

    .include "/etc/secadm.d/base.integriforce.rules"
}

Pages

Subscribe to HardenedBSD RSS