FreeBSD Security Information

Introduction

FreeBSD takes security very seriously and its developers are
constantly working on making the operating system as secure as
possible. This page will provide information about what to do in
the event of a security vulnerability affecting your system

When is a Security Advisory considered?

For every issue that gets reported, an internal tracking number is
created, unless something is very obviously not a security issue.
To determine whether or not a Security Advisory is warranted we use
the following scheme:

Is it a privilege escalation vulnerability?

Is it a code injection vulnerability?

Is it a memory disclosure or dataleak vulnerability?

From either the kernel

From a privileged process

From a process owned by another user?

Is it a Denial of Service vulnerability?

Only when remotely exploitable, where remotely means that it
comes from a different broadcast domain, so ARP and/or NDP based
attacks do not qualify.

Is it an unassisted jailbreak vulnerability?

Is it a malfunction that could lead to generating insecure crypto keys,
such as a PRNG bug?

For items that fall under these categories, a Security Advisory is very likely.
Items that are not on this list are looked into individually and it will be determined
then whether or not it will receive a Security Advisory or an Errata Notice.

Once it had been determined that a Security Advisory is warranted, either the
submitter delivers a CVE number if he/she already requested one, or we use one
from the FreeBSD pool available.

Recent FreeBSD security vulnerabilities

A full list of all security vulnerabilities affecting the base
system can be found on this
page.

Understanding FreeBSD security advisories

Advisories affecting the base system are sent to the following
mailing lists:

The FreeBSD Security Officer provides security advisories for
-STABLE Branches and the Security Branches.
(Advisories are not issued for the -CURRENT Branch,
which is primarily oriented towards FreeBSD developers.)

The -STABLE branch tags have names like stable/10.
The corresponding builds have names like FreeBSD
10.1-STABLE.

Each FreeBSD Release has an associated Security Branch.
The Security Branch tags have names like releng/10.1.
The corresponding builds have names like FreeBSD
10.1-RELEASE-p4.

How to update your system

For users that have previously installed a binary version of FreeBSD
(e.g., 12.0 or 11.2),
commands:

# freebsd-update fetch
# freebsd-update install

If that fails, follow the other instructions in the security
advisory you care about.

Note that the above procedure is only for users who have
previously installed a binary distribution. Those who have
built from source will need to update their source tree to
upgrade.

Supported FreeBSD releases

Each release is supported by the Security Officer for a limited
time only.

The designation and expected lifetime of all currently supported
branches
and their respective releases
are given below. The Expected EoL (end-of-life)
column indicates the earliest date on which support for that
branch or release will end. Please note that these dates may be
pushed back if circumstances warrant it.

Older releases
are not supported and users are strongly
encouraged to upgrade to one of these supported releases:

Branch

Release

Type

Release Date

Expected EoL

stable/12

n/a

n/a

n/a

June 30, 2024

releng/12.0

12.0-RELEASE

n/a

December 11, 2018

12.1-RELEASE + 3 months

stable/11

n/a

n/a

n/a

September 30, 2021

releng/11.2

11.2-RELEASE

n/a

June 28, 2018

11.3-RELEASE + 3 months

releng/11.3

11.3-RELEASE

n/a

July 9, 2019

11.4-RELEASE + 3 months (or September 30, 2021)

In the run-up to a release, a number of -BETA and -RC releases
may be published for testing purposes. These releases are only
supported for a few weeks, as resources permit, and will not be
listed as supported on this page. Users are strongly discouraged
from running these releases on production systems.

The FreeBSD support model

Under the current support model, each major version's stable branch
is explicitly supported for 5 years, while each individual point
release is only supported for three months after the next point
release.

The details and rationale behind this model can be found in the
official
announcement sent in February 2015.