From owner-freebsd-security Wed Feb 19 07:03:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26702 for security-outgoing; Wed, 19 Feb 1997 07:03:50 -0800 (PST) Received: from magrathea.chance.ru (root@magrathea.chance.ru [194.58.86.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA26695 for ; Wed, 19 Feb 1997 07:03:41 -0800 (PST) Received: (from caseq@localhost) by magrathea.chance.ru (8.6.12/8.6.12) id SAA11558; Wed, 19 Feb 1997 18:01:25 +0300 From: Andrew Kosyakov Message-Id: <199702191501.SAA11558@magrathea.chance.ru> Subject: Re: Coredumps and setuids .. interesting.. To: dg@root.com Date: Wed, 19 Feb 1997 18:01:24 +0300 (MSK) Cc: rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org In-Reply-To: <199702191337.FAA12198@root.com> from "David Greenman" at Feb 19, 97 05:37:20 am Organization: Chance Publishing House X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoting David Greenman: > >for any data stored in 'hash' dbm format. And, certainly, it _helped_ > >against *fptd/rlogin/screen vulnerabilities and didn't broke anything > It breaks performance when you have to zero out every bit of information > you get from a database. People might actually want their .db programs to > run *fast*, and this isn't a way to acheive that. Not that it was meant to :) But this argument looks weak to me -- how much performance degrade do you except form zeroing the page being released, considering that almost every page should be read from disk and sometimes written back, which is *much* more expensive operation. > >> you could still get it to coredump prior to it having a chance to zero > >> everything out). > >Why, it would be unwise of it to close data base before dropping root > >privileges (and in this case it will be impossible at all), and I won't be Arrggh, I meant "dropping privileges before closing base". > >able to send any signal to it unless it drops privileges. The case when it > A process running with set*id privileges doesn't mean that it can't receive > signals while it has them effective. In fact it can, the only requirement is > that the real uid of the process and the uid of the process sending the > signal be the same, and they will be in either case. BTW, running tests on 2.1.0 I couldn't make my test program (which only did gets() call to pause) dump core _if_ it was setuid. However, rlogin and screen do coredump. Is there an explanation to this fact? > Anything that does a seteuid will have the P_SUGID flag set internally, and > thus coredumps are prevented. If the process starts out as root and doesn't > issue any set*id calls, then the corefile will be owned by root with no > access to anyone...so there isn't a vulnerability in either case. Great... for a long term solution :) And is there any patch available for those, who still run 2.1.*? If no, I believe that one-line patch to libc will still protect them from at least 3 vulnerabilities.. -- Sincerely yours /&rew *** Andrew V. Kosyakov, Chance Publishing House, System Administrator caseq@chance.ru, 2:5030/31@Fidonet.Org, +7(812)210-8046 PGP key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF