Flaws in recent Linux kernels

Heimdall 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 
pretty solid
(Alan Cox told the same in the changelog for this kernel).
http://kernel.mirrors.easynet.fr/pub/linux/kernel/people/alan/linux-2.4/2.4.10/notes.2410

Heimdall

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?
>
>Jan
>
>
>On Thu, 18 Oct 2001 17:35:40 +0000, nergal at 7bulls.com (Rafal Wojtczuk)
>wrote:
>
> >Hello,
> >       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))
> >follows:
> >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
> >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.
> >       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
> >http://www.openwall.com/linux/
> >Note that the default Owl installation is not vulnerable to the ptrace bug
> >described.
> >
> >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,
> >Nergal
> >http://www.7bulls.com
> >
>
>--
>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 mailing list