COMMAND
	    procfs
SYSTEMS AFFECTED
	    FreeBSD, OpenBSD
PROBLEM
	    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.