Using FreeBSD’s pkg audit to Investigate Known Security Issues

Using FreeBSD’s pkg audit to Investigate Known Security Issues

One of the important tasks of any sysadmin/devop is keeping systems secure and free of vulnerabilities. FreeBSD systems come with several tools to accomplish that task for both its Base System and installed 3rdparty packages. Today we will discuss them in this brief article.

FreeBSD Base System

First we need to know which FreeBSD version we are running, and we can check that with the freebsd-version command. This command will print our current system version along with its patch level for both the kernel (installed version with -k and running version with -r switches respectively) and the userland (with -u switch).

To begin, we should make sure our installed FreeBSD version is still supported. To do that, visit the FreeBSD Release Information page. We will see there a list of supported releases, and the releases that are currently out of support. The Supported FreeBSD releases page shows the currently supported versions and their estimated EoL (End of Life) date. To learn more about the FreeBSD release cycle read this article on FreeBSD Release Engineering

This list of issued FreeBSD Security Advisories has all the information about vulnerabilities that have been discovered and corrected, where each post offers exact information of what could or should be done to make our system secure again. For example, check one of the recent OpenSSL advisories. The patches and additional files for each Security Advisory can be found on the page.

While OpenSSL is a separate open source project, FreeBSD incorporates it into the Base System, and thus the FreeBSD security team maintains security patches for OpenSSL. Each Security Advisory has the following structure:

I.   Background
II.  Problem Description
III. Impact
IV.  Workaround
V.   Solution
VI.  Correction details
VII. References

Sometimes, when dealing with so called ‘fine nines’ systems (systems that need to be up more than 99.999% of time), it may be necessary to carefully read all these sections and decide if that exact security hole affects us enough to justify the reboot to apply these security fixes. For example, if we find out that a new security hole is in the sendmail(8) mail server that we do not use then, depending on the nature of the hole, there is a chance that we could postpone these security updates to our next maintenance window instead of doing it immediately.

If the installed FreeBSD version is not on the supported list, then we will first have to upgrade it to a supported one. Here is the FreeBSD Handbook chapter that describes exactly that. It involves using the freebsd-update command.

While we will be upgrading our unsupported FreeBSD release to a supported one, we will also get the security patches in the process. While major and minor FreeBSD releases have the syntax of 13.0-RELEASE or 12.2-RELEASE, the security patches are in a form of -pX where X is a number that increases with each patch available for a given release. For example, 13.0-RELEASE-p1 is the name of the first patches available while 12.2-RELEASE-p9 is the ninth patched version available.

To check if there are patches available for our supported FreeBSD release, use the freebsd-update fetch command. We can also fetch these patches ‘automatically’ each night using the freebsd-update cron syntax in the crontab(5) file and then check if there are any patches fetched locally with the freebsd-update updatesready command. With the following entry in the crontab(5) file, we will automatically fetch the security updates between 2:00 AM and 3:00 AM.

0 2 * * * /usr/sbin/freebsd-update cron

Here is the output of the freebsd-update fetch command from 13.0-RELEASE system. As we can see in the output our FreeBSD system will be updated to the 13.0-RELEASE-p4 version.

# freebsd-update fetch
Looking up mirrors... 2 mirrors found.
Fetching public key from done.
Fetching metadata signature for 13.0-RELEASE from done.
Fetching metadata index... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 60 patches.....10....20....30....40....50....60 done.
Applying patches... done.
Fetching 34 files... ....10....20....30.. done.
The following files will be added as part of updating to
The following files will be updated as part of updating to

Once the patches are fetched, we can install them with usual freebsd-update install command.

You might also be interested in

Get more out of your FreeBSD development

Kernel development is crucial to many companies. If you have a FreeBSD implementation or you’re looking at scoping out work for the future, our team can help you further enable your efforts.

Installed Packages

We can install third party software on FreeBSD in many ways but the two most often used and supported ones are from the official FreeBSD pkg(8) binary packages, or by compiling software with the FreeBSD Ports framework. Both ‘latest’ and ‘quarterly’ pkg(8) branches have security patches available. Both branches get rebuilt every few days, however the ‘latest’ branch offers the most up-to-date versions of the software, while the ‘quarterly’ branch only receives security and bug fixes, and the versions of the software get updated every quarter (3 months). It is also possible to maintain a local pkg(8) repository with Poudriere – of which we talked about in a previous article.

While we can check the list of installed software using the pkg info command, there is a dedicated command to check if this installed software has any known security problems: pkg audit. Learn more about that in the pkg-audit(8) man page. It will show which software has which CVEs outstanding and links to these security advisories. It uses a database of security advisories maintained by port committers and the FreeBSD security team. There are several switches to control the output, -F makes sure that new definitions are fetched from the Internet every time we invoke the pkg audit command. The -q option will only print the names of the affected packages without CVEs and links to their descriptions. There is also the useful -R switch that will print the output in one of these machine readable formats: ucljsonjson-compactyaml. Below we will see pkg audit output when all packages in the system are secure.

# pkg audit -F
vulnxml file up-to-date
0 problem(s) in 0 installed package(s) found.

Next, the output on a system with packages that have vulnerabilities:

# pkg audit -F
vulnxml file up-to-date
chromium-92.0.4515.159_2 is vulnerable:
  chromium – use after free in Portals
  CVE: CVE-2021-37973

  chromium – multiple vulnerabilities
  CVE: CVE-2021-37980
  CVE: CVE-2021-37979
  CVE: CVE-2021-37978
  CVE: CVE-2021-37977

  chromium – multiple vulnerabilities
  CVE: CVE-2021-37976
  CVE: CVE-2021-37975
  CVE: CVE-2021-37974

3 problem(s) in 1 installed package(s) found.

Now that we know which packages have security holes, we can update them all with pkg upgrade or separately with pkg install package if we use the binary pkg(8) packages. If we need or prefer compilation from FreeBSD ports, we probably already have some manager for that task. The most widely used one is the portmaster(8) with which we can update all installed packages from source with portmaster -a command.

Rust Cargo Packages

Sometimes our software is not yet available in the FreeBSD Ports system and when that happens, we can install it using the Rust Cargo packages, for example. It’s quite convenient and easy with cargo install exa to install the exa(1) command for example. Fortunately for us, updating these packages is also easy, as we will find out below.

First, we need to install the cargo-update package. To do this, use the following command.

% cargo install cargo-update

    Updating index
  Downloaded cargo-update v7.0.1
  Downloaded 1 crate (44.4 KB) in 0.95s
  Installing cargo-update v7.0.1


    Finished release [optimized] target(s) in 4m 08s
  Installing /home/klarabsd/.cargo/bin/cargo-install-update
  Installing /home/klarabsd/.cargo/bin/cargo-install-update-config
   Installed package `cargo-update v7.0.1` (executables `cargo-install-update`, `cargo-install-update-config`)

The prompt above ‘%‘ is typical ‘user’ prompt because installing and using Rust Cargo packages does not require ‘root’ privileges as packages are installed in the ~/.cargo dir while compiled binaries go to ~/.cargo/bin directory. Keep in mind we should have that in our ${PATH} environment variable. Now we can update the Rust Carbo packages. Here’s how this is done.

% cargo install-update -a

    Updating registry ''

Package       Installed  Latest   Needs update
du-dust       v0.5.4     v0.7.0   Yes
rustcat       v0.0.5     v1.3.0   Yes
cargo-update  v7.0.1     v7.0.1   No


Updated 2 packages.
Overall updated 2 packages: du-dust, rustcat.

Keep in mind that this is a lengthy process as Rust compilation takes time. If we run the same command again, we see that we have the latest versions installed.

% cargo install-update -a

    Updating registry ''

Package       Installed  Latest   Needs update
cargo-update  v7.0.1     v7.0.1   No
du-dust       v0.7.0     v0.7.0   No
rustcat       v1.3.0     v1.3.0   No

No packages need updating.
Overall updated 0 packages.


With the above information we can now efficiently manage security vulnerabilities in our FreeBSD systems. Both in the Base System and installed packages … and also for Rust Cargo packages as a bonus!

Like this article? Share it!

You might also be interested in

Getting expert FreeBSD advice is as easy as reaching out to us!

At Klara, we have an entire team dedicated to helping you with your FreeBSD projects. Whether you’re planning a FreeBSD project, or are in the middle of one and need a bit of extra insight, we’re here to help!

More on this topic


OpenZFS Native Encryption

Beginning with version 13.0, FreeBSD supports the long-anticipated OpenZFS native encryption. If you’ve used FreeBSD’s GELI encryption in the past, you may wonder if switching to OpenZFS native encryption makes sense.

Check out the differences between GELI encryption and OpenZFS native encryption, and the main benefits of native encryption, let’s take a look at how to create an encrypted database and reroot to an encrypted database.

Demystifying OpenZFS 2.0

OpenZFS 2.0 has been released for a while now and, needless to say, FreeBSD 13 was shipped with OpenZFS 2.0. However, there are still questions about how the change from feature flags happened and why version 2.0 of OpenZFS was decided.
With this article, we’re hoping to clear the air around the release of OpenZFS 2.0.

Advanced ZFS Snapshots 

In our previous articles, we introduced you to the basics of ZFS snapshot management, and explained concepts such as creating OpenZFS snapshots, restoring files from a snapshot, and deleting snapshots.
With this article, we dive a bit deeper into OpenZFS snapshot management with snapshot holds, clone creation and promotion, and assigning permissions to snapshot-related operations.

Tell us what you think!