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 https://freebsd.org/security/patches/ 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 update.FreeBSD.org mirrors... 2 mirrors found.
Fetching public key from update2.freebsd.org... done.
Fetching metadata signature for 13.0-RELEASE from update2.freebsd.org... 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
13.0-RELEASE-p4:
/usr/include/c++/v1/barrier
/usr/include/c++/v1/concepts
/usr/include/c++/v1/execution
/usr/include/c++/v1/latch
/usr/include/c++/v1/numbers
/usr/include/c++/v1/semaphore
/usr/include/c++/v1/tr1/barrier
/usr/include/c++/v1/tr1/concepts
/usr/include/c++/v1/tr1/execution
/usr/include/c++/v1/tr1/latch
/usr/include/c++/v1/tr1/numbers
/usr/include/c++/v1/tr1/semaphore
The following files will be updated as part of updating to
13.0-RELEASE-p4:
/bin/freebsd-version
/boot/kernel/if_vlan.ko
/boot/kernel/ipdivert.ko
/boot/kernel/ipfw.ko
/boot/kernel/kernel
/boot/kernel/linux.ko
/boot/kernel/linux64.ko
/boot/kernel/mpt.ko
/boot/kernel/pmspcv.ko
/boot/kernel/virtio_blk.ko
/boot/kernel/virtio_pci.ko
/lib/libcasper.so.1
/lib/libcrypto.so.111
/rescue/[
/rescue/bectl
/rescue/bsdlabel
/rescue/bunzip2
/rescue/bzcat
/rescue/bzip2
/rescue/camcontrol
/rescue/cat
/rescue/ccdconfig
/rescue/chflags
/rescue/chgrp
/rescue/chio
/rescue/chmod
/rescue/chown
/rescue/chroot
/rescue/clri
/rescue/cp
/rescue/csh
/rescue/date
/rescue/dd
/rescue/devfs
/rescue/df
/rescue/dhclient
/rescue/disklabel
/rescue/dmesg

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
  WWW: https://vuxml.FreeBSD.org/freebsd/b6c875f1-1d76-11ec-ae80-704d7b472482.html

  chromium – multiple vulnerabilities
  CVE: CVE-2021-37980
  CVE: CVE-2021-37979
  CVE: CVE-2021-37978
  CVE: CVE-2021-37977
  WWW: https://vuxml.FreeBSD.org/freebsd/7d3d94d3-2810-11ec-9c51-3065ec8fd3ec.html

  chromium – multiple vulnerabilities
  CVE: CVE-2021-37976
  CVE: CVE-2021-37975
  CVE: CVE-2021-37974
  WWW: https://vuxml.FreeBSD.org/freebsd/777edbbe-2230-11ec-8869-704d7b472482.html

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 crates.io 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 'https://github.com/rust-lang/crates.io-index'

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 'https://github.com/rust-lang/crates.io-index'

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.

Summary

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

Avoid Vendor Lock-In with MinIO and OpenZFS

Modern web and mobile applications are increasingly dependent on software defined storage. Most commonly, this means Amazon Web Services’ S3 storage buckets. What you may not realize is that you don’t actually need Amazon for Amazon-compatible cloud storage! In this article, we’ll discuss how and why to avoid vendor lock-in by providing your apps fully S3-compatible storage using free and open source software.

Open Source Storage

5 Key Reasons to Consider Open Source Storage Over Commercial Offerings

Although easy to overlook, storage is the most fundamental part of any computing project—without storage, there is neither code nor data! The right storage solution should be accessible, reliable, easy to maintain, and free from vendor lock-in. In this article, we examine some of the reasons that open source software is a natural fit for this crucial component.

Part 3: Building Your Own FreeBSD-based NAS with ZFS 

Today, we’ll concentrate on exposing the data on your NAS to the network using NFS, Samba, and iSCSI shares. Network File System (NFS) is a commonly used protocol for accessing NAS systems, especially with Linux or FreeBSD clients. We’ll provide an overview of each type of share to help guide you in deciding which is most suited to the clients that will be accessing the NAS.
Let’s examine how non-developer contributors enhance user experience, improve bug reporting, and influence feature requests, all while becoming advocates and evangelists for your open source project.

One Comment on “Using FreeBSD’s pkg audit to Investigate Known Security Issues

  1. Pingback: Valuable News – 2021/12/13 | 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗

Tell us what you think!