Date: Tue, 16 Sep 1997 21:57:18 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: tqbf@silence.secnet.com, Don Lewis <Don.Lewis@tsc.tdk.com> Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals Message-ID: <199709170457.VAA26232@salsa.gv.tsc.tdk.com> In-Reply-To: tqbf@silence.secnet.com "Re: OpenBSD Security Advisory: BSD I/O Signals" (Sep 16, 9:55pm)
next in thread | raw e-mail | index | archive | help
On Sep 16, 9:55pm, tqbf@silence.secnet.com wrote: } Subject: Re: OpenBSD Security Advisory: BSD I/O Signals } } On Tue, 16 Sep 1997, Don Lewis wrote: } } > 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 } } It does. Note that F_SETOWN is literally a generic-file-descriptor wrapper } around TIOCSPGRP (check out the source), as well. Not in the case of sockets. If you do F_SETOWN on a socket, the kernel blindly accepts whatever process or group ID that you supply with no further checking. } > 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 } } The terminal code deals with pointers to proc structures, and the generic } device code deals with indexes into the process table; this is the reason } credential checking was added. The terminal code actually deals with a pointer to a process group structure, which points to a list of processes. I think the generic device code should do the same (with the added complications that the generic device code must allow individual processes to be specified, and process or process group may have multiple SIGIO sources). } > 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 } } Can you explain how this is a security-relevant proposal? It totally eliminates the wraparound problem. } The fix we've } provided is addressed at a very specific problem; it wasn't anyone's } intentions to change expected semantics, as you appear to suggest. It reduces the functionality somewhat. I have doubts as to whether anyone "expects" that functionality or would find it useful. } > I've got mixed feelings about credential checking. It doesn't eliminate } > inadvertent interference between processes with matching credentials when } } This would appear to be a general programming concern, and not a security } issue. It mostly is a general programming concern, but it can prevent apparently random things from happening. Now this is a stretch, but what if an attacker subverted a root owned process to to a F_SETOWN, change uid to some harmless user, and exec /bin/sh? Various unlucky processes would receive SIGIO signals, but no matter what you ran ktrace on, you wouldn't be able to find their sender. } > 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 } } If you could point out a specific instance in the code distributed with } FreeBSD, it'd be helpful (to clarify your meaning here). I seriously doubt there is any part of FreeBSD that uses the removed functionality. It's just that someone might find potentially find it useful ... } > 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. } } How does this increase security in the presence of strict credential } checking at signal delivery (a la csignal())? Innocent processes won't receive SIGIO even though they are unlucky enough to have a wrapped process ID, even though they have the same credentials as the process that did the F_SETOWN. Reliability is part of security ... } > Something else to consider is whether it makes sense to only send the signal } > to processes that have the object open. } } Given that this is not an established semantic and it isn't documented } anywhere, I think this might not be the most appropriate forum within } which to suggest such a change. Neh? It's another part of the big picture. It would increase security by limiting the processes that could be attacked and the functionality removed is probably slight. The downside would be the code bloat. } > In the case of the log device, F_SETOWN should probably be limited to } > root. } } In the case of the log device, F_SETOWN should be eliminated. Even better. --- Truck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709170457.VAA26232>