Date: Wed, 19 Feb 1997 18:01:24 +0300 (MSK) From: Andrew Kosyakov <caseq@magrathea.chance.ru> To: dg@root.com Cc: rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. Message-ID: <199702191501.SAA11558@magrathea.chance.ru> In-Reply-To: <199702191337.FAA12198@root.com> from "David Greenman" at Feb 19, 97 05:37:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702191501.SAA11558>