FreeBSD Security Advisory FreeBSD-SA-14:07.devfs
Wout Decré
wout at canodus.be
Wed Apr 30 09:23:18 UTC 2014
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
> To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org"
More information about the freebsd-security
mailing list