Date: Wed, 30 Apr 2014 11:16:49 +0200 From: Wout =?ISO-8859-1?Q?Decr=E9?= <wout@canodus.be> To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs Message-ID: <1398849409.4521.12.camel@debian.wout-t440s> In-Reply-To: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2014-04-30 at 04:35 +0000, FreeBSD Security Advisories wrote: > ============================================================================= > FreeBSD-SA-14:07.devfs Security Advisory > The FreeBSD Project > > Topic: devfs rules not applied by default for jails > > Category: core > Module: etc_rc.d > Announced: 2014-04-30 > Affects: FreeBSD 10.0 > Corrected: 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) > 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) > CVE Name: CVE-2014-3001 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit <URL:http://security.FreeBSD.org/>. > > I. Background > > The device file system, or devfs(5), provides access to kernel's device > namespace in the global file system namespace. > > The devfs(5) rule subsystem provides a way for the administrator of a system > to control the attributes of DEVFS nodes. Each DEVFS mount-point has a > ``ruleset'', or a list of rules, associated with it, allowing the > administrator to change the properties, including the visibility, of certain > nodes. > > II. Problem Description > > The default devfs rulesets are not loaded on boot, even when jails are used. > Device nodes will be created in the jail with their normal default access > permissions, while most of them should be hidden and inaccessible. > > III. Impact > > Jailed processes can get access to restricted resources on the host system. > For jailed processes running with superuser privileges this implies access > to all devices on the system. This level of access could lead to information > leakage and privilege escalation. > > IV. Workaround > > Systems that do not run jails are not affected. > > The system administrator can do the following to load the default ruleset: > > /etc/rc.d/devfs onestart > > Then apply the default ruleset for jails on a devfs mount using: > > devfs -m ${devfs_mountpoint} rule -s 4 applyset > > Or, alternatively, the following command will apply the ruleset over all devfs > mountpoints except the host one: > > mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | \ > xargs -n 1 -J % devfs -m % rule -s 4 applyset > > After this, the system administrator should add the following configuration > to /etc/rc.conf to make it permanent, so the above operations do not have > to be done each time the host system reboots. > > devfs_load_rulesets="YES" I have always used the following rc.conf options to start jails: jail_xxx_devfs_enable="YES" jail_xxx_devfs_ruleset="devfsrules_jail" If jail_xxx_devfs_enable is set to NO, would there be a problem? I thought you always had to set jail_xxx_devfs_ruleset when enabling devfs on jails. I think this has the same effect as the workaround above? > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 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. > > # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch > # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch.asc > # gpg --verify devfs.patch.asc > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > # install -o root -g wheel -m 444 etc/defaults/rc.conf /etc/defaults/ > > Follow the steps described in the "Workaround" section, or reboot the > system. > > 3) 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 > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > ------------------------------------------------------------------------- > stable/10/ r265122 > releng/10.0/ r265124 > ------------------------------------------------------------------------- > > 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:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>; > > VII. References > > <URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3001>; > > The latest revision of this advisory is available at > <URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-14:07.devfs.asc>; > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1398849409.4521.12.camel>