[UNIX] OpenBSD Bug Allows Unprivileged Users to Send SIGURG and SIGIO Signals
From: support@securiteam.comDate: 10/08/01
- Previous message: support@securiteam.com: "[UNIX] UnixWare 7 lpsystem Vulnerable to an Exploitable Buffer Overflow"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Subject: [UNIX] OpenBSD Bug Allows Unprivileged Users to Send SIGURG and SIGIO Signals Message-Id: <20011008182027.5D5F1138C4@mail.der-keiler.de> Date: Mon, 8 Oct 2001 20:20:27 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
OpenBSD Bug Allows Unprivileged Users to Send SIGURG and SIGIO Signals
------------------------------------------------------------------------
SUMMARY
A vulnerability in OpenBSD kernel 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 behavior 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.
DETAILS
Most UNIX systems provide an asynchronic I/O mechanism: every time data
arrives to a 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 necessary for a process to yield the ownership
of a file descriptor to another process (usually a child process).
A process should not yield ownership of a file descriptor to any process
in the system.
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 does not return an
error, instead now 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 does not
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 the check performed at signal delivery time will
always be cleared.
Unoffical patch:
*** uipc_socket2.c.old Sat Aug 18 16:10:40 2001
--- uipc_socket2.c Sat Aug 18 16:34:22 2001
***************
*** 176,181 ****
--- 176,186 ----
so->so_pgid = head->so_pgid;
so->so_euid = head->so_euid;
so->so_ruid = head->so_ruid;
+
+ so->so_siguid = head->so_siguid;
+ so->so_sigeuid = head->so_sigeuid;
+
+
(void) soreserve(so, head->so_snd.sb_hiwat, head->so_rcv.sb_hiwat);
soqinsque(head, so, soqueue);
if ((*so->so_proto->pr_usrreq)(so, PRU_ATTACH,
ADDITIONAL INFORMATION
The information has been provided by
<mailto:core.lists.bugtraq@core-sdi.com> Gustavo Ajzenman.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[UNIX] UnixWare 7 lpsystem Vulnerable to an Exploitable Buffer Overflow"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
