__________________________________________________________

                       The U.S. Department of Energy
                    Computer Incident Advisory Capability
                           ___  __ __    _     ___
                          /       |     /_\   /
                          \___  __|__  /   \  \___
             __________________________________________________________

                             INFORMATION BULLETIN

                         FreeBSD procfs Vulnerabilities

February 1, 2001 00:00 GMT                                        Number L-036
______________________________________________________________________________
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  The risk is HIGH. Local users could gain superuser privileges. 
ASSESSMENT:                                                                   
______________________________________________________________________________

[****** 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 <karin@root66.org> 
                Joost Pol <nohican@niets.org> (Problem #1, #2) 
                Esa Etelavuori <eetelavu@cc.hut.fi> (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/<pid>/mem and /proc/<pid>/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/<pid>/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/SA00:77/procfs.3.5.1.patch.v1.1 
# fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA00: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/SA00:77/procfs.4.1.patch 
# fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA00: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/SA00:77/procfs.4.2.patch 
# fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA00: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 ******]
______________________________________________________________________________
CIAC wishes to acknowledge the contributions of FreeBSD for the 
information contained in this bulletin.
______________________________________________________________________________


CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
    Voice:    +1 925-422-8193 (7x24)
    FAX:      +1 925-423-8002
    STU-III:  +1 925-423-2604
    E-mail:   ciac@llnl.gov

Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.

   World Wide Web:      http://www.ciac.org/
                        (or http://ciac.llnl.gov -- they're the same machine)
   Anonymous FTP:       ftp.ciac.org
                        (or ciac.llnl.gov -- they're the same machine)

PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins.  If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.

LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)

L-026: Microsoft Windows NT "Registry Permissions" Vulnerability
L-027: Win2000 "snmp" Vulnerability
L-028: Solaris arp(setgid) Vulnerability
L-029: FreeBSD "ipfw/ip6fw" Vulnerability
L-030: Four Vulnerabilities in ISC Bind
L-031: Sun AnswerBook2 Vulnerability
L-032: Class Loading Vulnerability in Sun Java (TM) Runtime Environment
L-033: Sun Java Web Server Vulnerability 
L-034: HP Security Vulnerability in man(1) Command
L-035: HP-UX Support Tools Manager Vulnerability