-----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-----