FreeBSD Security Advisories
2019-Jul-03 00:49 UTC
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-----
Ronald F. Guilmette
2019-Jul-03 01:55 UTC
FreeBSD Security Advisory FreeBSD-SA-19:11.cd_ioctl
In message <20190703004928.576CA1A7DE at freefall.freebsd.org>, freebsd-security at freebsd.org wrote:>Topic: Privilege escalation in cd(4) driver >... >devfs.conf(5) and devfs.rules(5) can be used to remove read permissions from >cd(4) devices.Would it be accurate to say that another possible workaround would be to simply remove the optical drive from the system(s) entirely? (I dunno about anybody else, but I personally don't even hardly use the bloody things anymore anyway.)