Date: Thu, 20 Jan 2000 17:34:13 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: Peter Wemm <peter@netplex.com.au>, current@freebsd.org, bde@freebsd.org, sheldonh@freebsd.org Subject: Re: Security hole with new setresuid call Message-ID: <Pine.BSF.4.21.0001201629070.2261-100000@alphplex.bde.org> In-Reply-To: <20000119035329.A65749@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Jan 2000, Andrey A. Chernov wrote: > On Tue, Jan 18, 2000 at 02:12:02PM +0800, Peter Wemm wrote: > > .. and why is this a security hole? setresuid(geteuid(), geteuid(), geteuid()) > > is equivalent to setuid(geteuid()).. > > Umm, maybe not the hole exactly, but difference between same area syscalls > implementation. Before setresuid() existed, the euid was known to be either the ruid or the svuid, so not checking in setreuid() for the new ruid being either the ruid or the svuid was just an optimization. setreuid() has the interesting implementation detail of setting the svuid to the euid. I think we did this mainly to avoid surprises in old programs that don't know about the svuid, but it has some side effects: (1) it allows unprivileged callers to change the svuid. (2) it maintains the "known" property. setresuid() now allows even unprivileged callers to break the "known" property: starting from a normal setuid setup with svuid == euid, setresuid(euid, ruid, euid) swaps the ruid with the euid like setreuid(euid, ruid), but it doesn't adjust the svuid. Possible fixes 1) change setreuid() to allow new_ruid == euid, etc. 2) do nothing. Programs shouldn't set the svuid to a non-working value if it hurts when they do that. setresuild() now allows privileged callers to set the ids to 3 different values. This may confuse later operation of the process. Fix: don't do that. > We define POSIX_APPENDIX_B_4_2_2 by default for setuid(geteuid()), but I > mean case when it is _not_ defined (BTW, why to have define which is > always on?) It's like the _POSIX_SAVED_IDS define which is always off. It was written before we learned to bury mistakes in the repository :-). > And in case POSIX_APPENDIX_B_4_2_2 is not defined, > ruid = euid; > assignment was not allowed before you add new syscall. It could be done using: seteuid(ruid); setuid(ruid); /* To set svuid too. */ but allowed it dierectly in setuid() to support programs that don't understand BSD4.4 seteuid(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001201629070.2261-100000>