Vulnerability

    procfs

Affected

    FreeBSD, OpenBSD

Description

    Frank van  Vliet, Joost  Pol and  Esa Etelavuori  found following.
    procfs  is  the  process  filesystem,  which presents a filesystem
    interface to  the system  process table,  together with associated
    data.

    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.

Solution

    To work around  problems 1 and  2, perform the  following steps as
    root:

        * Unmount all instances of the procfs filesystem
          # 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.   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.

    For FreeBSD:

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

    OpenBSD also issued patch.