FreeBSD Security Advisories
2007-Jan-11 10:41 UTC
FreeBSD Security Advisory FreeBSD-SA-07:01.jail
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
============================================================================FreeBSD-SA-07:01.jail
Security Advisory
The FreeBSD Project
Topic: Jail rc.d script privilege escalation
Category: core
Module: etc_rc.d
Announced: 2007-01-11
Credits: Dirk Engling
Affects: All FreeBSD releases since 5.3
Corrected: 2007-01-11 18:16:58 UTC (RELENG_6, 6.2-STABLE)
2007-01-11 18:17:24 UTC (RELENG_6_2, 6.2-RELEASE)
2007-01-11 18:18:08 UTC (RELENG_6_1, 6.1-RELEASE-p12)
2007-01-11 18:18:35 UTC (RELENG_6_0, 6.0-RELEASE-p17)
2007-01-11 18:18:57 UTC (RELENG_5, 5.5-STABLE)
2007-01-11 18:19:33 UTC (RELENG_5_5, 5.5-RELEASE-p10)
CVE Name: CVE-2007-0166
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 jail(2) system call allows a system administrator to lock a process
and all of its descendants inside an environment with a very limited
ability to affect the system outside that environment, even for
processes with superuser privileges. It is an extension of, but
far more powerful than, the traditional UNIX chroot(2) system call.
The host's jail rc.d(8) script can be used to start and stop jails
automatically on system boot/shutdown.
II. Problem Description
In multiple situations the host's jail rc.d(8) script does not check if
a path inside the jail file system structure is a symbolic link before
using the path. In particular this is the case when writing the
output from the jail start-up to /var/log/console.log and when
mounting and unmounting file systems inside the jail directory
structure.
III. Impact
Due to the lack of handling of potential symbolic links the host's jail
rc.d(8) script is vulnerable to "symlink attacks". By replacing
/var/log/console.log inside the jail with a symbolic link it is
possible for the superuser (root) inside the jail to overwrite files
on the host system outside the jail with arbitrary content. This in
turn can be used to execute arbitrary commands with non-jailed
superuser privileges.
Similarly, by changing directory mount points inside the jail file
system structure into symbolic links, it may be possible for a jailed
attacker to mount file systems which were meant to be mounted inside
the jail at arbitrary points in the host file system structure, or to
unmount arbitrary file systems on the host system.
NOTE WELL: The above vulnerabilities occur only when a jail is being
started or stopped using the host's jail rc.d(8) script; once started
(and until stopped), running jails cannot exploit this.
IV. Workaround
If the sysctl(8) variable security.jail.chflags_allowed is set to 0
(the default), setting the "sunlnk" system flag on /var, /var/log,
/var/log/console.log, and all file system mount points and their
parent directories inside the jail(s) will ensure that the console
log file and mount points are not replaced by symbolic links. If
this is done while jails are running, the administrator must check
that an attacker has not replaced any directories with symlinks
after setting the "sunlnk" flag.
V. Solution
NOTE WELL: The solution described changes the default location of the
"console.log" for jails from /var/log/console.log inside each jail to
/var/log/jail_${jail_name}_console.log on host system. If this is a
problem, it may be possible to create a hard link from the new position
of the console log file to a location inside the jail. A new rc.conf(5)
variable, jail_${jail_name}_consolelog, can be used to change the
location of console.log files on a per-jail basis.
In addition, the solution described below does not fully secure jail
configurations where two jails have overlapping directory trees and a
file system is mounted inside the overlap. Overlapping directory
trees can occur when jails share the same root directory; when a jail
has a root directory which is a subdirectory of another jail's root
directory; or when a part of the file system space of one jail is
mounted inside the file system space of another jail, e.g., using
nullfs or unionfs.
To handle overlapping jails safely the administrator must set the
sysctl(8) variable security.jail.chflags_allowed to 0 (the default)
and manually set the "sunlnk" file/directory flag on all mount points
and all parent directories of mount points. If this is done while
jails are running, the adminstrator must check that an attacker has
not replaced any directories with symlinks after setting the "sunlnk"
flag.
Perform one of the following:
1) Upgrade your vulnerable system to 5-STABLE, or 6-STABLE, or to the
RELENG_6_1, RELENG_6_0, or RELENG_5_5 security branch dated after the
correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 5.5, 6.0,
and 6.1 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 5.5]
# fetch http://security.FreeBSD.org/patches/SA-07:01/jail5.patch
# fetch http://security.FreeBSD.org/patches/SA-07:01/jail5.patch.asc
[FreeBSD 6.0]
# fetch http://security.FreeBSD.org/patches/SA-07:01/jail60.patch
# fetch http://security.FreeBSD.org/patches/SA-07:01/jail60.patch.asc
[FreeBSD 6.1]
# fetch http://security.FreeBSD.org/patches/SA-07:01/jail61.patch
# fetch http://security.FreeBSD.org/patches/SA-07:01/jail61.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# install -o root -g wheel -m 555 etc/rc.d/jail /etc/rc.d
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_5
src/etc/rc.d/jail 1.15.2.6
RELENG_5_5
src/UPDATING 1.342.2.35.2.10
src/sys/conf/newvers.sh 1.62.2.21.2.12
src/etc/rc.d/jail 1.15.2.5.2.1
RELENG_6
src/etc/rc.d/jail 1.23.2.9
RELENG_6_2
src/UPDATING 1.416.2.29.2.2
src/etc/rc.d/jail 1.23.2.7.2.1
RELENG_6_1
src/UPDATING 1.416.2.22.2.14
src/sys/conf/newvers.sh 1.69.2.11.2.14
src/etc/rc.d/jail 1.23.2.3.2.3
RELENG_6_0
src/UPDATING 1.416.2.3.2.22
src/sys/conf/newvers.sh 1.69.2.8.2.18
src/etc/rc.d/jail 1.23.2.2.2.1
- -------------------------------------------------------------------------
VII. References
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0166
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-07:01.jail.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFpoQEFdaIBMps37IRAqtSAJoDNEO9woA7ZF1hbCuhbjFzhnXSfgCgjRH/
bapC5/eS7eAipiguG2DFdls=a8el
-----END PGP SIGNATURE-----
Colin Percival
2007-Jan-11 16:50 UTC
HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the "NOTE WELL" part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail), make an assumption about how systems are configured (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). While this is not ideal, this security issue was extraordinarily messy due to the power and flexibility of the jails and the jail rc.d script. I can't recall any other time when the security team has spent this long trying to find a working patch for a security issue. I'd like to publicly thank Simon Nielsen for the many many hours he spent working on this issue, as well as the release engineering team for being very patient with us and delaying the upcoming release to give us time to fix this. Sincerely, Colin Percival FreeBSD Security Officer FreeBSD Security Advisories wrote:> ============================================================================> FreeBSD-SA-07:01.jail Security Advisory > The FreeBSD Project > > Topic: Jail rc.d script privilege escalation > > [snip] > > NOTE WELL: The solution described changes the default location of the > "console.log" for jails from /var/log/console.log inside each jail to > /var/log/jail_${jail_name}_console.log on host system. If this is a > problem, it may be possible to create a hard link from the new position > of the console log file to a location inside the jail. A new rc.conf(5) > variable, jail_${jail_name}_consolelog, can be used to change the > location of console.log files on a per-jail basis. > > In addition, the solution described below does not fully secure jail > configurations where two jails have overlapping directory trees and a > file system is mounted inside the overlap. Overlapping directory > trees can occur when jails share the same root directory; when a jail > has a root directory which is a subdirectory of another jail's root > directory; or when a part of the file system space of one jail is > mounted inside the file system space of another jail, e.g., using > nullfs or unionfs. > > To handle overlapping jails safely the administrator must set the > sysctl(8) variable security.jail.chflags_allowed to 0 (the default) > and manually set the "sunlnk" file/directory flag on all mount points > and all parent directories of mount points. If this is done while > jails are running, the adminstrator must check that an attacker has > not replaced any directories with symlinks after setting the "sunlnk" > flag. > > [snip] > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-07:01.jail.asc
Dirk Engling
2007-Jan-16 02:17 UTC
HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Colin Percival wrote:> No. `cp -f` unlinks the existing file and creates a new file, but will > still follow a symlink if one is created between the "unlink" syscall and > the "open" syscall. > > /* remove existing destination file name, > * create a new file */ > (void)unlink(to.p_path); > if (!lflag) > to_fd = open(to.p_path, O_WRONLY | O_TRUNC | O_CREAT, > fs->st_mode & ~(S_ISUID | S_ISGID));You are right. Atomically in binary is not atomical enough. mv in its rename()-form will do the job, so we need to create a file in . by mktemp and mv it to the real name when filled. Regards erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFrDWmImmQdUyYEgkRAgSgAJ0c5mcaM4LByBUE0LC1Iqdj8ZFSAACdF9qM fFETX4I+Fvue0u+343bBG8c=MkSh -----END PGP SIGNATURE-----