From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 09:33:16 2010 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5780F1065672 for ; Tue, 10 Aug 2010 09:33:16 +0000 (UTC) (envelope-from snabb@epipe.com) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:470:8940:10::1]) by mx1.freebsd.org (Postfix) with ESMTP id EFDC78FC22 for ; Tue, 10 Aug 2010 09:33:15 +0000 (UTC) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:470:8940:10::1]) by tiktik.epipe.com (8.14.4/8.14.4) with ESMTP id o7A9XFvR034999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Aug 2010 09:33:15 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com o7A9XFvR034999 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1281432795; x=1282037595; bh=Oxyd96zbOPdqZOYluGnc4+TNhQ4SMqsiwiBpdXuO4lo=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=VaP0xE2hEGm2aduAHpg+w0kLxPBrX80ALHGSAJxbl0tOlCG5wJ8IPzXIvucH2p8Mv qgNXhUtGdVvE5OPTlPq4Drj45BPVyiLszw/n35r+RJxjTd3DnvW24QCkd6l5nhLBhA mHVqc8Qklzy8yNqA+lpJs7rPUTaIjr6+SDDGM4c8= Date: Tue, 10 Aug 2010 09:33:15 +0000 (UTC) From: Janne Snabb To: freebsd-security@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: ~/.login_conf mechanism is flawed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 09:33:16 -0000 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/