Date: Tue, 10 Aug 2010 09:33:15 +0000 (UTC) From: Janne Snabb <snabb@epipe.com> To: freebsd-security@freebsd.org Subject: ~/.login_conf mechanism is flawed Message-ID: <alpine.BSF.2.00.1008100841350.96753@tiktik.epipe.com>
index | next in thread | raw e-mail
Hi, I am posting to a public list as this issue has been already disclosed publicly on full-disclosure mailing list. This looks a bit worrying: http://lists.grok.org.uk/pipermail/full-disclosure/2010-August/075944.html Looks like the per-user login capability database (~/.login_conf, ~/.login_conf.db) functionality is creating a vulnerability. What I found especially worrying is that this user-supplied untrustable file is being parsed and processed by various daemons and other login mechanisms BEFORE permanently dropping root privileges. Unless there is a very strong reason, which I am overlooking, to do so, I find this design very flawed. It makes the following possible for example: - System administrator sets a limit (for example datasize) in /etc/login.conf to a certain class of users, and expects it to limit those users' use of system resources. - User creates their own .login_conf where they set the limit unlimited. This succeeds because the user's .login_conf{,.db} is processed before dropping privileges. The problematic execution order is evident by doing for example the following: - Enable tracing of sshd and its child processes (as root): # ktrace -i -p `cat /var/run/sshd.pid` - Log in as normal user with sshd from other terminal and do nothing there. Just log out immediately or whatever. - Stop the trace: # ktrace -C - Examine the execution order in the trace (pay attention to process ID numbers): # kdump | grep ' sshd ' | grep 'NAMI.*/.login.conf\|set.*uid' | less I think that the following is needed: - Change the execution order in several daemons, maybe in PAM? /usr/bin/login? - Fix the database handling routines (the problem pointed out in HI-TECH's e-mail to full-disclosure). Even if the user-specific login capabilities database is being processed in the user's context, this might still allow for example breaking to /bin/sh from an (authorized) ftp-only account. - Add a flag in global login capababilities database for choosing whether the per-user login capabilities should be processed and make it DISABLED default. User-specific .login_conf{,.db} would be processed only if excplicitly enabled by the administrator. I think this bug goes in to a class of local privilege escalation. Am I missing something obvious? What do you think? -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1008100841350.96753>