The description of the second problem is accurate, but I don't think the assessment of the kernels which can or cannot be affected by this exploit is... I'm using a newly compiled kernel Linux 2.4.12-grsec-1.8.3. ( Linux 2.4.12 with the Grsecurity Patch http://www.grsecurity.net/features.htm ) # /* begin shell session */ [12:52:11][apokalyptik@home:~]: ./epcs_ptrace_attach_exploit bug exploited successfully. enjoy! sh-2.05$ # /* end shell session */ -- Demitrious S. Kelly -----Original Message----- From: Rafal Wojtczuk [mailto:nergal@7bulls.com] Sent: Thursday, October 18, 2001 10:36 AM To: bugtraq@securityfocus.com Subject: Flaws in recent Linux kernels II. Root compromise by ptrace(3) In order for this flaw to be exploitable, /usr/bin/newgrp must be setuid root and world-executable. Additionally, newgrp, when run with no arguments, should not prompt for password. This conditions are satisfied in case of most popular Linux distributions (but not Openwall GNU/*/Linux). Suppose the following flow of execution (initially, Process 1 and Process 2 are unprivileged): Time Process 1 Process 2 0 ptrace(PTRACE_ATTACH, pid of Process 2,...) 1 execve /usr/bin/newgrp 2 execve /any/thing/suid 3 execve default user shell 4 execve ./insert_shellcode The unexpected happens at moment 2. Process 2 is still traced, execve /any/thing/suid succeeds, and the setuid bit is honored ! This is so because 1) the property of "having an ptrace-attached child" survives the execve 2) at moment 2, the tracer (process 1) has CAP_SYS_PTRACE set (well, has all root privs), therefore it is allowed to trace even execve of setuid binary. In moment 3, newgrp executes a shell, which is an usual behavior. This shell is still able to control the process 2 with ptrace. Therefore, the "./insert_shellcode" binary is able to insert arbitrary code into the address space of Process 2. Game over. 2.4.12 kernel fixes both presented problems. The attached patches, 2.2.19-deep-symlink.patch and 2.2.19-ptrace.patch, both blessed by Linus, can be used to close the vulnerability in 2.2.19. The (updated) Openwall GNU/*/Linux kernel patches can be retrieved from http://www.openwall.com/linux/ Note that the default Owl installation is not vulnerable to the ptrace bug described.
