Vulnerability Update: libarchive

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

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

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"

New stable release: HardenedBSD-stable 10-STABLE v46.2

HardenedBSD-10-STABLE-v46.2 -

This is a security update, but by default none of the currently released FreeBSD SAs affect HardenedBSD, since we fixed the libarchive issue in v46.1 and the COMPAT layers are disabled by default.


Subscribe to HardenedBSD RSS