[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
- read forum
- new topic
- search

- meetings list
- recent additions
- add your info
 top 100 sites
- visit top sites
- sign up now
- members

- add your url
- add domain
- search box
- link to us

- our projects
- free email
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : Several vulnerabilities in procfs

Title: Several vulnerabilities in procfs
Released by: FreeBSD
Date: 18th December 2000
Printable version: Click here


FreeBSD-SA-00:77                                            Security Advisory

                                                                FreeBSD, Inc.

Topic:          Several vulnerabilities in procfs

Category:       core

Module:         procfs

Announced:      2000-12-18

Affects:        Problem #1: FreeBSD 4.x prior to the correction date.

                            FreeBSD 3.x is unaffected.

                Problem #2, #3: FreeBSD 4.x and 3.x prior to the correction


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

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 4.x systems where procfs is mounted,

unprivileged local users can obtain root privileges.

2) On vulnerable FreeBSD 4.x and 3.x systems where procfs is mounted,

unprivileged local users can cause the system to hang.

3) On vulnerable FreeBSD 4.x and 3.x 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)


# 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           procfs  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


  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 4.2-STABLE 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 http://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.3.5.1.patch

# fetch http://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.3.5.1.patch.asc

Verify the detached PGP signature using your PGP utility.

[FreeBSD 4.1-RELEASE and FreeBSD 4.1.1-RELEASE]

# fetch http://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.4.1.patch

# fetch http://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.4.1.patch.asc

Verify the detached PGP signature using your PGP utility.


# fetch http://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:77/procfs.4.2.patch

# fetch http://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 -f -a -t procfs


Version: GnuPG v1.0.4 (FreeBSD)

Comment: For info see http://www.gnupg.org







(C) 1999-2000 All rights reserved.