Fw: Flaws in recent Linux kernels
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 ->
>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
> 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
> 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.
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