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.
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.
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.
Disclaimer: The data contained on this page is derived from the VuXML document, please refer to the the original document for copyright information. The author of portaudit makes no claim of authorship or ownership of any of the information contained herein.
If you have found a vulnerability in a FreeBSD port not listed in the database, please contact the FreeBSD Security Team. Refer to "FreeBSD Security Information" for more information.