OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Steve (stevesecuresolutions.org)
Date: Thu Oct 18 2001 - 14:05:18 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    -----Original Message-----
    From: Rafal Wojtczuk [mailto:nergal7bulls.com]
    Subject: Flaws in recent Linux kernels

    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