The OpenNET Project
 
Search (keywords):  SOFT ARTICLES TIPS & TRICKS SECURITY
LINKS NEWS MAN DOCUMENTATION


OpenBSD bug


<< Previous INDEX Search src Set bookmark Go to bookmark Next >>
Date: Fri, 5 Oct 2001 19:26:07 -0300
From: Gustavo Ajzenman <core.lists.bugtraq@core-sdi.com.>
To: [email protected]
Subject: OpenBSD bug

------=_NextPart_000_004C_01C14DD3.94B850B0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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
[email protected]

Florida 141  |  2╨ cuerpo  |  7╨ piso
(C1005AAC) Buenos Aires  |  Argentina
Tel/Fax : (54 11) 4878-CORE (2673)
[email protected]  |  www.corest.com

------=_NextPart_000_004C_01C14DD3.94B850B0 Content-Type: application/octet-stream; name="uipc_socket2.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="uipc_socket2.patch"
  • uipc_socket2.c.old Sat Aug 18 16:10:40 2001=0A= --- uipc_socket2.c Sat Aug 18 16:34:22 2001=0A= ***************=0A=
  • 176,181 ****=0A= --- 176,186 ----=0A= so->so_pgid =3D head->so_pgid;=0A= so->so_euid =3D head->so_euid;=0A= so->so_ruid =3D head->so_ruid;=0A= + =0A= + so->so_siguid =3D head->so_siguid;=0A= + so->so_sigeuid =3D head->so_sigeuid;=0A= + =0A= + =0A= (void) soreserve(so, head->so_snd.sb_hiwat, head->so_rcv.sb_hiwat);=0A= soqinsque(head, so, soqueue);=0A= if ((*so->so_proto->pr_usrreq)(so, PRU_ATTACH,=0A= ------=_NextPart_000_004C_01C14DD3.94B850B0-- --- for a personal reply use: "Gustavo Ajzenman" <gustavo@core-sdi.com.>

  • << Previous INDEX Search src Set bookmark Go to bookmark Next >>



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру