Date: Tue, 16 Sep 1997 20:35:13 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals Message-ID: <199709170335.UAA26150@salsa.gv.tsc.tdk.com> In-Reply-To: tqbf@rdist.org "OpenBSD Security Advisory: BSD I/O Signals" (Sep 15, 1:06am)
next in thread | raw e-mail | index | archive | help
On Sep 15, 1:06am, tqbf@rdist.org wrote: } Subject: OpenBSD Security Advisory: BSD I/O Signals } In cases where multiple processes are used in an application, it becomes } useful to allow a descriptor to notify other processes as well. This is } accomplished by use of another fcntl() operation, F_SETOWN, as well as an } ioctl, FIOSETOWN (certain devices also provide an interface to this } facility with the TIOCSPGRP ioctl). These operations allow a program to } set the process or process group that will receive signal notification of } pending I/O. Should the argument to F_SETOWN undergo similar checks as the argument to tcsetpgrp()? I don't think it makes sense to allow F_SETOWN to enable signals to be sent to processes in a different session. There probably need to be more calls to setsid() sprinkled around as well, for instance in inetd. } A lack of checking in the code that handles these operations allows a } program to specify an arbitrary process ID when using a socket or device } file descriptor. By setting the recipient of signal notification to a } process that is not owned by the program, the kernel can be tricked into } signalling arbitrary programs. } } Additionally, vulnerable kernels do not keep track of the credentials } associated with a process when determining whether to send I/O signals; } because of this, it is possible to specify the PID of a process that is } owned by an attacker, and then destroy that process and wait for it's PID } to be re-used. The new process occupying that PID can then be signalled by } the attacker, regardless of it's owner. I think a better cure for the wraparound problem is to solve it the same was as it is handled for controlling terminals. When the process group associated with a controlling terminal disappears, the terminal loses it's process group and it no longer can send signals. This would have to be extended to handle either processes or process groups for F_SETOWN. This also has some positive performance implications, since it potentially bypasses a lot calls to pfind() and pgfind(). } It's important to note that operating systems that check credentials when } a program attempts to set the PID for I/O notification (thus evading part } of this vulnerability) may still be vulnerable to the latter problem } (process ID re-use), if credentials aren't checked at signal delivery } time. I've got mixed feelings about credential checking. It doesn't eliminate inadvertent interference between processes with matching credentials when wraparound occurs, it doesn't cause a diagnostic to be returned if something bogus is done with F_SETOWN, and there may be cases where someone wants to use several cooperating processes with different credentials but sharing the same socket (though I really can't think of any and it looks like the patch allows this to work if root does the F_SETOWN). IMHO, the change to disable signal sending when the process or process group disappears should definitely be implemented. It increases security, there is no loss of functionality, and there is likely to be increased performance. The session and/or the credential checks should probably be implemented. Both of these limit functionality to some extent, but not enough to outweigh the increased security. Something else to consider is whether it makes sense to only send the signal to processes that have the object open. } Unfortunately, the log device is normally accessible by users, and can be } used to perform the same attack as sockets allow. It's also worth noting } that the interface that allows programs to set the process to receive } notification of I/O on the log device renders the legitimate purpose of } this facility totally unreliable; unrelated programs can seize control of } the asynchronous I/O notification on the log device, causing programs that } rely on it to fail. The provided patches do not attempt to resolve this } problem. In the case of the log device, F_SETOWN should probably be limited to root. --- Truck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709170335.UAA26150>