Date: Tue, 10 Aug 2010 17:36:12 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Przemyslaw Frasunek <przemyslaw@frasunek.com> Cc: freebsd-security@freebsd.org Subject: Re: ~/.login_conf mechanism is flawed Message-ID: <86fwym32fn.fsf@ds4.des.no> In-Reply-To: <4C611FA9.6070409@frasunek.com> (Przemyslaw Frasunek's message of "Tue, 10 Aug 2010 11:45:13 %2B0200") References: <alpine.BSF.2.00.1008100841350.96753@tiktik.epipe.com> <4C611FA9.6070409@frasunek.com>
index | next in thread | previous in thread | raw e-mail
Przemyslaw Frasunek <przemyslaw@frasunek.com> writes: > 41513 ftpd CALL seteuid(0xbb8) > 41513 ftpd RET seteuid 0 > 41513 ftpd NAMI "/home/venglin/.login_conf" > 41513 ftpd NAMI "/home/venglin/.login_conf.db" > 41513 ftpd NAMI "/home/venglin/.login_conf.db" login_getclassbyname() temporarily drops privs while reading the user's .login_conf, because the user's ~ may be on (for instance) an NFS mount with -maproot=nobody. Janne's mistake is to assume that reading == processing. However, he is correct in that in the event of an exploitable code injection vulnerability in the code that *reads* the file, the injected code can easily reacquire root privs. There is a different issue documented in PR bin/141840 which results in the user's resource limits being processed *with* root privs in certain circumstances. It so happens that in FreeBSD, those circumstances only arise in OpenSSH. This does not mean that the bug is in OpenSSH; it's in setusercontext(3), which makes unwarranted assumptions about how it is being called. Unfortunately, that PR arrived at a time when so@ was busy with far more important issues, and it fell through the cracks. The good news is that the the only settings that can be overridden in this manner are resource limits and the CPU mask. DES -- Dag-Erling Smørgrav - des@des.nohome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86fwym32fn.fsf>