-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-20:01.ssp Errata Notice
The FreeBSD Project
Topic: Imprecise ordering of SSP canary initialization
Category: core
Module: libc
Announced: 2020-01-28
Credits: Kyle Evans
Affects: All supported versions of FreeBSD.
Corrected: 2019-11-25 03:49:38 UTC (stable/12, 12.1-STABLE)
2020-01-28 18:53:14 UTC (releng/12.1, 12.1-RELEASE-p2)
2020-01-28 18:53:14 UTC (releng/12.0, 12.0-RELEASE-p13)
2019-11-25 03:49:38 UTC (stable/11, 11.3-STABLE)
2020-01-28 18:53:14 UTC (releng/11.3, 11.3-RELEASE-p6)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
.
I. Background
The Stack Smashing Protector ("SSP") relies on a stack canary being
initialized early on in application startup. On FreeBSD, this is
accomplished with a constructor in libc.
II. Problem Description
When a binary is statically linked, constructor invocation order is based on
priority and sorted arbitrarily within a priority level across all
constructors present in the single statically linked object. The stack
canary guard constructor had no priority, so statically linked binary could
not predictably order their constructors to avoid bad interactions with
respect to the stack canary constructor leading to false-positive detection
of a stack overflow condition and erroneous process abort in some rare cases.
Dynamically linked binaries are generally not affected, since the stack
canary is initialized in libc and libc is ordered very early in constructor
invocation.
III. Impact
Affected programs will abort and log a "stack overflow detected" message to
syslog(3).
IV. Workaround
No workaround is available, but dynamically linked binaries are not affected.
V. Solution
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date. Statically linked binaries
should be relinked against the updated base system.
Perform one of the following:
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
2) To update your system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch https://security.FreeBSD.org/patches/EN-20:01/ssp.patch
# fetch https://security.FreeBSD.org/patches/EN-20:01/ssp.patch.asc
# gpg --verify ssp.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in .
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r355080
releng/12.1/ r357215
releng/12.0/ r357215
stable/11/ r355080
releng/11.3/ r357215
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
VII. References
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl4whbdfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cKWSA/8CINmMeEm76kGRoyuDiTD+h1Ra28DM81+HNsTuEb8W8uhNT/ZJf61lWZe
c5BEO8uJMP8XUjGEzIEu4ARkZcV2pvLxyUIoWgq1TGTYB7jp8zXeJZj/wPqLLpI4
lwXl19hWPprz1CDgukR87+flDZyNEe62YfAtL3WRqGuYU8Yb6AmNoKSwOphset4m
6F7pg8wPFnHfW2EOl6/jFZsv41C+2SlIXa8HIXFJj0TnfltLsCqEWhpDhVE0Wv0D
f2MCGs03xS+UN/kUGIE6G2WBD/Etfy4DMr7RsRxu1lta6FhOk8sR27FCcSnqyKPM
MqXK0PxN5qx8D2UbQUhNCmmclnOVjzGEn9ECzxW5XrDsz17bhodtL4f29GmLEw4l
wdHcttUlQduzolZlBgKgNyp6ZuKXXYzPYsATgJTG9LBQShyQeWa4rCz21Nh+vrmA
NdSAY/LEvq6R8IKHFljDwFIPITnV6xQObMIDgrsJMFyFyIUGiZEo0Jo51I28aUJ/
EM76+SULzxY50Agw5KFgCM1iXPfGnEfPN03wNCzrbvpv3y67qduGF4jbmLMZPcnv
aZBVQj4Cx9Q/pC/TCFNilmmEa3/xYDB6hGnQn9cIYBV1Q61IQXwGaGXNG+fN760x
gYfnbY2ZlJVV66amfTC89HNVwMeq++Imd4AzNlaXV+a9qummNKc=
=VzHc
-----END PGP SIGNATURE-----