Flaws in recent Linux kernels
heimdall at e-phoria.net
Fri Oct 19 01:11:48 PDT 2001
I'm under kernel 2.4.10 ac 12 without problems at the moment and it seems
(Alan Cox told the same in the changelog for this kernel).
At 09:28 19/10/2001 +0200, you wrote:
>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
> >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
> >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,
> >/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
> >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
> >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
> >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
> >output. This technique (stderr redirected to a pipe, LD_DEBUG set,
> >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
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