Date: Tue, 16 Sep 1997 22:30: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: <199709170530.WAA26272@salsa.gv.tsc.tdk.com> In-Reply-To: tqbf@silence.secnet.com "Re: OpenBSD Security Advisory: BSD I/O Signals" (Sep 16, 11:15pm)
next in thread | raw e-mail | index | archive | help
On Sep 16, 11:15pm, tqbf@silence.secnet.com wrote: } Subject: Re: OpenBSD Security Advisory: BSD I/O Signals } } On Tue, 16 Sep 1997, Don Lewis wrote: } } > 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. } } You're saying that, after the OpenBSD patch, arbitrary processes can } continue to SIGIO/SIGURG arbitrary other processes? Not totally arbitrary, the patch limits the victims to those that pass the credential test. } > } Can you explain how this is a security-relevant proposal? } > It totally eliminates the wraparound problem. } } As does credential checking at signal delivery. Only for those processes with different credentials. } > 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 } } The hole would be in the program that allowed an attacker to gain root } access to fcntl, and there's not much you can do in the kernel to prevent } the general case of this from remaining true. Generally if root can be subverted to do F_SETOWN, you're probably in a lot deeper trouble, but this does the door open to a weak but very stealthy attack. Instead of generally trashing things, an attacker could just make the system work slightly out of kilter and they don't even to keep the root process running which might raise suspicions. The attacker only needs to run an innocent looking process to keep the socket open. This situation could also occur by accident. All it takes is a root process that uses F_SETOWN and then forks a child which inherits the fd. If the parent process happens to die, the signals will get delivered to whatever processes are assigned the old ID of the parent. } > 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 ... } } If the process has the exact same credentials, how is this a security } issue? I think we're reaching a bit here. ... or any process if root did the F_SETOWN. I agree that this is reaching a bit. --- Truck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709170530.WAA26272>