Fw: Flaws in recent Linux kernels

Jan Stifter j.stifter at medres.ch
Fri Oct 19 00:28:39 PDT 2001

I am sure you have heard about it (it is at bugtraq). There seems to
be also the problem in kernel 2.4.12, as another message stated. Any
comments / suggestions, which kernel should be used?


On Thu, 18 Oct 2001 17:35:40 +0000, nergal at 7bulls.com (Rafal Wojtczuk)

>	There are two bugs present in Linux kernels 2.2.x, x<=19 and 2.4.y, 
>y<=9. The first vulnerability results in local DoS. The second one,
>involving ptrace, can be used to gain root privileges locally (in case of 
>default install of most popular distributions). Linux 2.0.x is not vulnerable 
>to the ptrace bug mentioned.
>I. Local DoS via deep symlinks
>	An attacker can force the kernel to spend almost 
>arbitrary amount of time on dereferencing a single symlink, which prevents
>other processes from running. The attached 
>script, mklink.sh, takes a single 
>parameter N. The script creates 5 symlinks, each of 
>them containing 2*N+1 path elements. When N=3, the symlinks look this way:
>$ ls -lG
>drwxr-xr-x    2 nergal       4096 wrz 21 14:46 l
>lrwxrwxrwx    1 nergal         53 wrz 21 14:46 l0 ->
>	l1/../l1/../l1/../l/../../../../../../../etc/services
>lrwxrwxrwx    1 nergal         19 wrz 21 14:46 l1 -> l2/../l2/../l2/../l
>lrwxrwxrwx    1 nergal         19 wrz 21 14:46 l2 -> l3/../l3/../l3/../l
>lrwxrwxrwx    1 nergal         19 wrz 21 14:46 l3 -> l4/../l4/../l4/../l
>lrwxrwxrwx    1 nergal         19 wrz 21 14:46 l4 -> l5/../l5/../l5/../l
>drwxr-xr-x    2 nergal       4096 wrz 21 14:46 l5
>drwxr-xr-x    2 rybagowa     4096 lut 27  1999 still_here
>The amount of time the command "head l0" consumes (measured with time(1)) 
>N	system time
>10:     sys     0m0.050s
>20:     sys     0m1.400s
>30:     sys     0m10.150s
>40:     sys     0m41.840s
>	When "head l0" is being executed, other processes are not scheduled to
>run. Thus the possibility of local DoS (in case of SMP you may need to spawn 
>one mklink.sh process per cpu). The time spent on dereferencing "l0" is 
>proportional to the number of path elements in normalized "l0". So, when 
>N=120, the scheduler should be locked out for about three hours. One can 
>reach N=600, in case of 2.4.9; also in case of 2.4.9, one can create even more 
>(up to eight) levels of symlinks.
>	2.4.10 fixed this problem, but not completely. Under 2.4.10 "head
>l0" command would not block the scheduler, but it cannot be killed. The
>problem is fully solved in 2.4.12. 
>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 
>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.
>	In order to exploit this kernel vulnerability, one needs a setuid
>root binary which execs an user-defined binary (or a shell). Newgrp is
>appropriate on most distributions. On default install of slackware it does
>not work (the password fields in /etc/group are empty, and newgrp demands a
>password). However, one can use "su" on this distribution. "su" 
>binary is compiled without PAM support on slackware, therefore it execs an
>user shell.
>	Do you remember the exploit against *BSD procfs, published in
>January 2000 (http://www.securityfocus.com/cgi-bin/archive.pl?id=1&mid=43189) ? 
>This one is very similar; a setuid binary is spawned so that the system treats
>it as a tracing process. Observe that in case of newgrp, only CAP_SYS_SETGID
>is required (plus probably some reserved egid E to read gshadow; provided that
>gshadow would be readable by gid E). If the file system supported granting 
>capabilities to programs (not only +s bit), this bug could have been benign. 
>Similarly, "su" needs only CAP_SYS_SETUID+CAP_SYS_SETGID (and egid shadow). 
>The "least privilege" rule, strictly applied, can save from a lot of 
>unexpected trouble.
>	This bug seems to be Linux-specific. I have tested FreeBSD, OpenBSD
>and [older versions of] Irix and Solaris. None of the tested systems 
>honored setuid bit when an executing process was traced, even when the 
>tracer was root.
>III. Vendor status
>	The kernel developers were notified on 18th September. 
>vendor-sec at lists dot de was notified on 9th October.
>IV. Availability of patches.
>	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
>Note that the default Owl installation is not vulnerable to the ptrace bug
>V. The exploits
>	The attached mklink.sh script creates malicious symlinks. 
>	ptrace-exp.c and insert_shellcode.c exploit the ptrace bug on i386
>architecture. You will probably need to adjust #define in the latter. Note 
>that ptrace-exp uses LD_DEBUG variable to force a setuid program to generate 
>output. This technique (stderr redirected to a pipe, LD_DEBUG set, especially 
>LD_DEBUG=symbols) allows for forced suspending of a setuid binary in a 
>precisely determined moments, which may be helpful to build exploits which 
>rely on race-conditions. And finally, notice that under Owl LD_DEBUG is 
>ignored in case of suid binaries. 
>Save yourself,

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-security' in the subject header of the message

More information about the lfs-security mailing list