FreeBSD Security Advisories
2019-Jul-03 00:49 UTC
[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-19:11.cd_ioctl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================FreeBSD-SA-19:11.cd_ioctl Security Advisory The FreeBSD Project Topic: Privilege escalation in cd(4) driver Category: core Module: kernel Announced: 2019-07-02 Credits: Alex Fortune Affects: All supported versions of FreeBSD. Corrected: 2019-07-03 00:11:31 UTC (stable/12, 12.0-STABLE) 2019-07-02 00:03:55 UTC (releng/12.0, 12.0-RELEASE-p7) 2019-07-03 00:12:50 UTC (stable/11, 11.3-PRERELEASE) 2019-07-02 00:03:55 UTC (releng/11.3, 11.3-RC3-p1) 2019-07-02 00:03:55 UTC (releng/11.2, 11.2-RELEASE-p11) CVE Name: CVE-2019-5602 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background The cd(4) driver implements a number of ioctls to permit low-level access to the media in the CD-ROM device. The Linux emulation layer provides a corresponding set of ioctls, some of which are implemented as wrappers of native cd(4) ioctls. These ioctls are available to users in the operator group, which gets read-only access to cd(4) devices by default. II. Problem Description To implement one particular ioctl, the Linux emulation code used a special interface present in the cd(4) driver which allows it to copy subchannel information directly to a kernel address. This interface was erroneously made accessible to userland, allowing users with read access to a cd(4) device to arbitrarily overwrite kernel memory when some media is present in the device. III. Impact A user in the operator group can make use of this interface to gain root privileges on a system with a cd(4) device when some media is present in the device. IV. Workaround devfs.conf(5) and devfs.rules(5) can be used to remove read permissions from cd(4) devices. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Perform one of the following: 1) To update your vulnerable 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 Afterwards, reboot the system. 2) To update your vulnerable 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. [FreeBSD 12.x] # fetch https://security.FreeBSD.org/patches/SA-19:11/cd_ioctl.12.patch # fetch https://security.FreeBSD.org/patches/SA-19:11/cd_ioctl.12.patch.asc # gpg --verify cd_ioctl.12.patch.asc [FreeBSD 11.x] # fetch https://security.FreeBSD.org/patches/SA-19:11/cd_ioctl.11.patch # fetch https://security.FreeBSD.org/patches/SA-19:11/cd_ioctl.11.patch.asc # gpg --verify cd_ioctl.11.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/12/ r349628 releng/12.0/ r349625 stable/11/ r349629 releng/11.3/ r349625 releng/11.2/ r349625 - ------------------------------------------------------------------------- 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: <URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN> VII. References <URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5602> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-19:11.cd_ioctl.asc> -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl0b9WtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cK+nBAAqVz2kEviqpD6wTqwmDexacApQ8aRrnxUDA/PSU/ZStdU3/E3OHAEwMOr k3qNBbMYUO5alXyLfe9Gv2iP2eTD8QP6xafMiwvcMxS2aJe6ieRmRTLUbep0QBEN weIaafjvIlLElJTWb9Rr5CTUs6sSdq7Jc84dHPHSOQehhkCFydTdHCaYtvRS2tg1 YYyzMdTlT1VRCL3Rb6iHkqLG7JKX1fTLsPxXGqv/IjYAcDREZjVNhxjvcsQsMQxD 2tTBDVZZLJBOHshGg/kyCRB++d36JNED0kb7/lfohGBvZS6wtmbe9z3a1+S4MN9i sxNdLc4a/Qr3iP4SzgGf6YuD/BmXg/7HWZnBj220VncVHYjQThAZih0VDUSy9zBy EplpqcRYebzvAQkq63e2LE66rveX58L7KAzZDG2QJUrPDJAfxgdc1fslgm/+/Yck /lHVG8gxJNr+tpC80vKxssS7WhNUnd1zThKa2D5rrFnsWUR5da66mxJelUrq+vPT bhs/nHOzqqXpojh+j/8a6q8Wi2CDSGnJ9vtt0FZu7SG0/r7hlUAAuI0o9VJV/Uh4 CyJeVlJ65+4bUm+k9qFBxsmd7S08f1Z6UND8/1ffFOYm4POVJcRa1wUswYjXPfjp Sf0rZ5vCq8TG7EOcdMHqHBgAumx3gAXj+I73Lwm73vnP4jMoqmw=Bc/8 -----END PGP SIGNATURE-----
Walter Cramer
2019-Jul-04 14:18 UTC
?Minor Security Issue - DNS, /etc/hosts, freebsd-update, ?pkg
Suspected severity: Low. Systems with inattentive administrators may not receive the latest updates, and no obvious error messages will point out the problem. Situation discovered in: A few older 11.2-RELEASE FreeBSD systems, with /etc/hosts entries like this: 96.47.72.72 ftp.freebsd.org 96.47.72.71 pkg.freebsd.org (Those are now obsolete. Originally, they were added to simplify firewall rules and rule-loading, and as a DNS hijack defense.) Resulting problem: `freebsd-update fetch` sometimes "sees" the latest (11.2-RELEASE-p11) version of 11.2. Other times, it "sees" the older 11.2-RELEASE-p10. So, if a sysadmin relied on `freebsd-update` to tell him when systems needed updating, he could be unaware of un-patched, vulnerable systems. NOT verified: Whether the obsolete /etc/hosts entry for pkg.freebsd.org actually causes any problems. (Or if `pkg` is aware of the problem, and silently doing all the right things.) Suggested Fixes... - Have `freebsd-update`, `pkg`, and similar utilities double-check for DNS information that is obsolete or conflicting, and warn the user. - Have any obsolete - but still-active - pkg or update servers advertise their obsolete status, and `freebsd-update` and `pkg` notice that, and warn the user.