|
|
| PROBLEM: | Several vulnerabilities have been discovered in FreeBSD's implementation of the process filesystem (procfs). |
| PLATFORM: | FreeBSD 4.x and 3.x prior to the correction date. 2000-12-16 (FreeBSD 4.2-STABLE), 2000-12-18 (FreeBSD 3.5.1-STABLE). |
| DAMAGE: | On vulnerable FreeBSD systems where procfs is mounted, unprivileged local users can obtain root privileges or cause the system to hang. On vulnerable FreeBSD systems, superusers who can load the procfs filesystem, or on systems where it is already mounted, can bypass access control checks in the kernel. |
| SOLUTION: | Upgrade the vulnerable FreeBSD system to 3.5.1-STABLE or 4.2-STABLE dated after the correction date, or patch your present system source code and rebuild. Refer to section V. of this bulletin for additional information. |
| VULNERABILITY ASSESSMENT: |
The risk is HIGH. Local users could gain superuser privileges. |
[****** Start FreeBSD Advisory ******]
=============================================================================
FreeBSD-SA-00:77 Security Advisory
FreeBSD, Inc.
Topic: Several vulnerabilities in procfs [REVISED]
Category: core
Module: procfs
Announced: 2000-12-18
Reissued: 2000-12-29
Affects: FreeBSD 4.x and 3.x prior to the correction date.
Corrected: 2000-12-16 (FreeBSD 4.2-STABLE)
2000-12-18 (FreeBSD 3.5.1-STABLE)
Credits: Frank van Vliet
Joost Pol (Problem #1, #2)
Esa Etelavuori (Problem #3)
FreeBSD only: NO
0. Revision History
v1.0 2000-12-18 Initial release.
v1.1 2000-12-29 Note FreeBSD 3.x also vulnerable to problem #1 (local
root vulnerability), update 3.x patch, correct typo in
mount command.
I. Background
procfs is the process filesystem, which presents a filesystem interface to the
system process table, together with associated data.
II. Problem Description
There were several problems discovered in the procfs code:
1) Unprivileged local users can gain superuser privileges due to insufficient
access control checks on the /proc//mem and /proc//ctl files, which
gives access to a process address space and perform various control operations
on the process respectively.
The attack proceeds as follows: the attacker can fork() a child process and
map the address space of the child in the parent. The child process then
exec()s a utility which runs with root or other increased privileges. The
parent process incorrectly retains read and write access to the address space
of the child process which is now running with increased privileges, and can
modify it to execute arbitrary code with those privileges.
2) Unprivileged local users can execute a denial of service against the local
machine by mmap()ing a processes own /proc//mem file in the procfs
filesystem. This will cause the system to enter into an infinite loop in the
kernel, effectively causing the system to hang until manually rebooted by an
administrator on the system console.
3) Users with superuser privileges on the machine, including users with root
privilege in a jail(8) virtual machine, can overflow a buffer in the kernel
and bypass access control checks placed on the abilities of the superuser.
These include the ability to "break out" of the jail environment (jail is
often used as a compartmentalization tool for security purposes), to lower the
system securelevel without requiring a reboot, and to introduce new (possibly
malicious) code into the kernel on systems where loading of KLDs (kernel
loadable modules) has been disabled.
III. Impact
1) On vulnerable FreeBSD systems where procfs is mounted, unprivileged local
users can obtain root privileges.
2) On vulnerable FreeBSD systems where procfs is mounted, unprivileged local
users can cause the system to hang.
3) On vulnerable FreeBSD systems, superusers who can load the procfs
filesystem, or on systems where it is already mounted, can bypass access
control checks in the kernel which would otherwise limit their abilities.
Consequences include the ability to break out of a jail environment, to lower
securelevel or to introduce malicious code into the kernel on systems where
loading of KLDs has been disabled. For many systems this vulnerability is
likely to have minor impact.
IV. Workaround
To work around problems 1 and 2, perform the following steps as root:
Unmount all instances of the procfs filesystem using the umount(8) command:
# umount -f -a -t procfs
Disable the automatic mounting of all instances of procfs in /etc/fstab:
remove or comment out the line(s) of the following form:
proc /proc 0procfs rw 0 0
The linprocfs filesystem, which provides additional interfaces to Linux
binaries to emulate the Linux procfs filesystem, is believed not to be
vulnerable to the problems described in this advisory and therefore does not
need to be unmounted. Note however that some Linux binaries may require the
presence of both procfs and linprocfs in order to function correctly.
To work around problem 3 is more difficult since it involves the superuser,
but the following steps are believed to be sufficient:
? Unmount all procfs filesystems which are visible from within jail
environments, to prevent a jail root compromise from compromising the
entire system. Since jailed users do not have the ability to mount
filesystems, a successful jail root compromise in a jail without procfs
visible cannot exploit this vulnerability.
? Remove the "options PROCFS" line from your kernel configuration file, if
present, and compile a new kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html
If the running kernel was compiled with "options PROCFS", then any user who
has root privileges can mount procfs and exploit vulnerability 3,
regardless of system securelevel.
If the kernel does not include this option, then an attempt to mount procfs
will trigger a load of the procfs.ko KLD module, which is denied at
securelevel greater than zero. Since this vulnerability only has meaning
(in the case of unjailed root users) on systems which are kept in a
securelevel greater than zero, this will always be true, and such systems
are not vulnerable to the problem.
Note that unmounting procfs may have a negative impact on the operation of the
system: under older versions of FreeBSD it is required for some aspects of the
ps(1) command, and it may also break use of userland inter-process debuggers
such as gdb. Other installed binaries including emulated Linux binaries may
require access to procfs for correct operation.
V. Solution
Upgrade your vulnerable FreeBSD system to 3.5.1-STABLE or 4.2-STABLE dated
after the correction date, or patch your present system source code and
rebuild.
To patch your present system: download the relevant patch from the below
location, and execute the following commands as root:
[FreeBSD 3.5.1-RELEASE]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.3.5.1.patch.v1.1
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.3.5.1.patch.v1.1.asc
Verify the detached PGP signature using your PGP utility.
[FreeBSD 4.1-RELEASE and FreeBSD 4.1.1-RELEASE]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.4.1.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.4.1.patch.asc
Verify the detached PGP signature using your PGP utility.
[FreeBSD 4.2-RELEASE]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.4.2.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.4.2.patch.asc
Verify the detached PGP signature using your PGP utility.
# cd /usr/src/sys
# patch -p < /path/to/patch
If procfs is statically compiled into the kernel (e.g. the kernel
configuration file contains the line 'options PROCFS'), then rebuild and
reinstall your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the system with
the new kernel for the changes to take effect.
If procfs is dynamically loaded by KLD (use the kldstat command to verify
whether this is the case) and the system securelevel has not been raised, then
the system can be patched at run-time without requiring a reboot, by
performing the following steps after patching the source as described above:
# cd /usr/src/sys/modules/procfs
# make all install
# umount -f -a -t procfs
# kldunload procfs # kldload procfs
# mount -a -t procfs
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
[****** End FreeBSD Advisory ******]
Voice: +1 925-422-8193 (7 x 24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@llnl.gov
World Wide Web: http://www.ciac.org/
http://ciac.llnl.gov
(same machine -- either one will work)
Anonymous FTP: ftp.ciac.org
ciac.llnl.gov
(same machine -- either one will work)