This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

------=_NextPart_000_004C_01C14DD3.94B850B0
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.NEB.4.33.0110091641482.14748@odysseus.mono.org>

=09Would this be relevant to NetBSD?

--=20
=09=09David/absolute=09=09abs@formula1.com

---------- Forwarded message ----------
Date: Fri, 5 Oct 2001 19:26:07 -0300
From: Gustavo Ajzenman <core.lists.bugtraq@core-sdi.com>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: OpenBSD bug

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 b=
e
an effective Denial of Service mechanism for processes that catch each of
the two.

    Another vulnerability with the same consecuences was published and fixe=
d
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. Thi=
s
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 returne=
d
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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ CORE Security Technologies ]=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Gustavo Ezequiel Ajzenman
Sofware Developer
gustavo.ajzenman@corest.com

Florida 141  |  2=BA cuerpo  |  7=BA piso
(C1005AAC) Buenos Aires  |  Argentina
Tel/Fax : (54 11) 4878-CORE (2673)
info.argentina@corest.com  |  www.corest.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

------=_NextPart_000_004C_01C14DD3.94B850B0
Content-Type: APPLICATION/OCTET-STREAM; NAME="uipc_socket2.patch"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.NEB.4.33.0110091641483.14748@odysseus.mono.org>
Content-Description: 
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--