Jako chyba pierwsi na świecie podajemy dokładną informację o błędzie w kernelach serii 2.2.19, 2.4.9 i starszych jądrach tych serii. Kod eksploita – usunęliśmy, jednak prawdopodobnie już wkrótce pojawi się na Bugtraq. Upgrade jądra zalecany…

  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      

Archiwalny news dodany przez użytkownika: honey.
Kliknij tutaj by zobaczyć archiwalne komentarze.

Oznaczone jako → 
Share →