-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:13.nullfs Security Advisory The FreeBSD Project Topic: Cross-mount links between nullfs(5) mounts Category: core Module: nullfs Announced: 2013-09-10 Credits: Konstantin Belousov Affects: All supported versions of FreeBSD. Corrected: 2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC3-p1) 2013-09-10 10:15:33 UTC (releng/9.1, 9.1-RELEASE-p7) 2013-09-10 10:12:09 UTC (stable/8, 8.4-STABLE) 2013-09-10 10:14:19 UTC (releng/8.4, 8.4-RELEASE-p4) 2013-09-10 10:13:14 UTC (releng/8.3, 8.3-RELEASE-p11) CVE Name: CVE-2013-5710 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The nullfs(5) filesystem allows all or a part of an already mounted filesystem to be made available in a different part of the global filesystem namespace. It is commonly used to make a set of files available to multiple chroot(2) or jail(2) environments without replicating the files in each environment. A common idiom, described in the FreeBSD Handbook, is to mount one subtree of a filesystem read-only within a jail's filesystem namespace, and mount a different subtree of the same filesystem read-write. II. Problem Description The nullfs(5) implementation of the VOP_LINK(9) VFS operation does not check whether the source and target of the link are both in the same nullfs instance. It is therefore possible to create a hardlink from a location in one nullfs instance to a file in another, as long as the underlying (source) filesystem is the same. III. Impact If multiple nullfs views into the same filesystem are mounted in different locations, a user with read access to one of these views and write access to another will be able to create a hard link from the latter to a file in the former, even though they are, from the user's perspective, different filesystems. The user may thereby gain write access to files which are nominally on a read-only filesystem. IV. Workaround No workaround is available, but systems which do not use the nullfs(5) filesystem, or do not null-mount different subtrees of the same source filesystem with different permissions, are not vulnerable. 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-13:13/nullfs.patch # fetch http://security.FreeBSD.org/patches/SA-13:13/nullfs.patch.asc # gpg --verify nullfs.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and 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/8/ r255445 releng/8.3/ r255446 releng/8.4/ r255447 stable/9/ r255443 releng/9.1/ r255448 releng/9.2/ r255444 - ------------------------------------------------------------------------- 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----- Version: GnuPG v1.4.14 (FreeBSD) iEYEARECAAYFAlIu+7EACgkQFdaIBMps37K+7gCfVrmhwyE+k5QU3Z4wsdJFoeyL BqEAn23QlLQ7o4HlDSiJuPoX622IsFbk =/7Zz -----END PGP SIGNATURE-----