OpenBSD bug

From: Gustavo Ajzenman (core.lists.bugtraq@core-sdi.com)
Date: Fri Oct 05 2001 - 15:26:07 PDT

  • Next message: Don: "Re: AIM 0day DoS"

    Hi
    
        I recently found a vulnerability in OpenBSD kernel that allows any user
    capable of executing a process to deliver SIGURG and SIGIO signals to any
    process (or group of process) owned by any user in the system. Although the
    default behaviour in OpenBSD is to ignore these signals, this issue could be
    an effective Denial of Service mechanism for processes that catch each of
    the two.
    
        Another vulnerability with the same consecuences was published and fixed
    in Linux and OpenBSD (http://www.openbsd.org/advisories/signal.txt). The
    vendor was already notified, and the issue was fixed but probably other bsd
    systems (such as NetBSD and FreeBSd) may be affected. Attached to this mail
    is a non official patch that fix the problem.
    
    
    Here is the technical description:
    
        Most Unix systems provide an asynchronic I/O mechanism: every time data
    arrives to an specific file descriptor, the operating system notifies the
    owner with a signal (SIGIO). In the case of sockets the process is notified
    when a packet with the Out of Band flag arrives with the SIGURG signal. This
    mechanism is activated through the function fcntl, with O_ASYNC flag, or
    ioctl with FIOASYNC.
        Which process is notified depends on the ownership of the file
    descriptor.
    Generally the owner of a file descriptor is the creator (the process that
    calls the socket function in the case of sockets). Under some circumstances
    it could be necesary for a process to yield the ownership of a file
    descriptor to another process (usually a child process).
    
        A process shouldn't yield ownership of a file descriptor to any process
    in the system. This issue was addressed in the bug already mentioned
    (http://www.openbsd.org/advisories/signal.txt).
    
        The management of the permissions to set the owner of a file descriptor
    is handled differently in Linux and OpenBSD. In linux, an EPERM error is
    returned when someone attempts to set the owner of a file descriptor to a
    process of another user. In OpenBSD, the function doesn't return an error,
    instead at the moment the system must deliver a signal, permissions are
    checked and a decision is made.
        To accomplish this check in the case of sockets, the OpenBSD kernel
    stores in the internal structure of each socket: so_siguid and so_sigeuid,
    with the information of the process that sets the ownership. This keeps an
    unauthorized process from opening, setting the asynchronous flag, or
    changing the ownership of a given file descriptor, and the delivery of
    signals.
    
        When a socket waits for connections using accept the new socket returned
    inherits the properties of the first socket.
    The bug exists in the routine that creates the new connected socket,
    sonewconn1. This routing doesn't copy the so_siguid y so_sigeuid fields of
    the socket structure. They are reset to zero in the new socket.
    Taking advantage of these two facts together, it is possible to create a
    socket, assign ownership to a different process, call accept and have the
    so_siguid and so_sigeuid flags resetted. This will leave us with a socket
    with a different owner than our process id, and with with the check
    performed at signal delivery time will always be cleared.
    
    Gustavo Ajzenman
    
    ==============[ CORE Security Technologies ]===============
    Gustavo Ezequiel Ajzenman
    Sofware Developer
    gustavo.ajzenmanat_private
    
    Florida 141  |  2º cuerpo  |  7º piso
    (C1005AAC) Buenos Aires  |  Argentina
    Tel/Fax : (54 11) 4878-CORE (2673)
    info.argentinaat_private  |  www.corest.com
    ===================================================
    
    
    

    --- for a personal reply use: "Gustavo Ajzenman" <gustavo@core-sdi.com>



    This archive was generated by hypermail 2b30 : Sat Oct 06 2001 - 10:37:46 PDT