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/ From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 09:45:37 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 C77C5106567A for ; Tue, 10 Aug 2010 09:45:37 +0000 (UTC) (envelope-from przemyslaw@frasunek.com) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2001:1a68:2:2::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3FF218FC2A for ; Tue, 10 Aug 2010 09:45:37 +0000 (UTC) Received: from [193.138.118.100] (ip-193-138-118-100.nette.pl [193.138.118.100]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id C1DD8239466 for ; Tue, 10 Aug 2010 11:44:50 +0200 (CEST) Message-ID: <4C611FA9.6070409@frasunek.com> Date: Tue, 10 Aug 2010 11:45:13 +0200 From: Przemyslaw Frasunek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ~/.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:45:37 -0000 > 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. This seems to be incorrect for both ftpd and sshd on 6.4-RELEASE. 41673 sshd CALL setuid(0xbb8) 41673 sshd RET setuid 0 41673 sshd CALL seteuid(0xbb8) 41673 sshd RET seteuid 0 41673 sshd NAMI "/home/venglin/.login_conf" 41673 sshd NAMI "/home/venglin/.login_conf.db" 41673 sshd NAMI "/home/venglin/.login_conf.db" 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" Back in 2001 I found a very similar vulnerability in 4.4-RELEASE, which allowed to read any file in system with root privileges: http://marc.info/?l=bugtraq&m=100101802423376&w=2 Since then, elevated privileges are dropped before parsing login_conf. -- * Fido: 2:480/124 ** WWW: http://www.frasunek.com ** NICHDL: PMF9-RIPE * * Jabber ID: venglin@nette.pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ5JIV * From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 10:02:42 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 A8297106566C for ; Tue, 10 Aug 2010 10:02:42 +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 495AE8FC24 for ; Tue, 10 Aug 2010 10:02:42 +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 o7AA2ZK3024953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 10:02:35 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com o7AA2ZK3024953 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1281434555; x=1282039355; bh=sBgSMP9x0VB6A/efY6cB09Q0r0tU+on7xGZnybwMV9Y=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=TdwVe4H22KuT5Cc/KilmPuS4c10469jpAbHb3X3LjsY/EEnXeWybA9g10jfRkFpkI lrU+xIFZ6h3083n11wxKw3AAzfWUOCAs031aq8P6iEhp7SmnbEowvn7oOeIiPkT7aa SNDB91eFHYQmEoVy6qJV6SeXh/RrzfELGmM0J3oY= Date: Tue, 10 Aug 2010 10:02:35 +0000 (UTC) From: Janne Snabb To: Przemyslaw Frasunek In-Reply-To: <4C611FA9.6070409@frasunek.com> Message-ID: References: <4C611FA9.6070409@frasunek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org Subject: Re: ~/.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 10:02:42 -0000 On Tue, 10 Aug 2010, Przemyslaw Frasunek wrote: > This seems to be incorrect for both ftpd and sshd on 6.4-RELEASE. > > 41673 sshd CALL setuid(0xbb8) > 41673 sshd RET setuid 0 > 41673 sshd CALL seteuid(0xbb8) > 41673 sshd RET seteuid 0 > 41673 sshd NAMI "/home/venglin/.login_conf" > 41673 sshd NAMI "/home/venglin/.login_conf.db" > 41673 sshd NAMI "/home/venglin/.login_conf.db" The above actually seems correct to me. Both uid and euid are set before accessing the capabilities. On 8.1-RELEASE this is different, only euid is set to the user (to make it possible to access this file if the home directory happens to be NFS mounted without root access?). > 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" This is clearly wrong, it is still possible to change euid back to 0. It is still possible to setrlimit() anything. > Back in 2001 I found a very similar vulnerability in 4.4-RELEASE, which allowed > to read any file in system with root privileges: > > http://marc.info/?l=bugtraq&m=100101802423376&w=2 Hehe... I was about to try out this one next. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 15:25:43 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 586CB1065674 for ; Tue, 10 Aug 2010 15:25:43 +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 E85D68FC1E for ; Tue, 10 Aug 2010 15:25:42 +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 o7AFPgM5072234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Aug 2010 15:25:42 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com o7AFPgM5072234 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1281453942; x=1282058742; bh=SiirlGEV0W4my7gxo7PM86gvOTScgBBl6k07UfGSixw=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=lBb1R0Hp9yhOvTZLTFkZDT6I79QRICVasu2AkwosAyP3nsIL7GALCZPfMcJVOCB4n kpOoNAzY1rMuEeohgizn9J4t8ZM6DSr9ePa1+BpXivb3lpgLGCHxTNKH/1Kjj8WPp7 I/m9JR0OUSQ9fYziFrz0U2lkTyGyxnOx7StMBY7k= Date: Tue, 10 Aug 2010 15:25:42 +0000 (UTC) From: Janne Snabb To: freebsd-security@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1852024168-802663992-1281453942=:96753" Subject: Re: ~/.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 15:25:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1852024168-802663992-1281453942=:96753 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Aug 2010, Janne Snabb wrote: > Looks like the per-user login capability database (~/.login_conf, > ~/.login_conf.db) functionality is creating a vulnerability. Attached is a temporary workaround for anyone who is worried about this problem. It disables per-user login capability databases completely. Only the system wide /etc/login.conf is used. Do not apply the patch if you need per-user login capabilities. This should work on 8.1-RELEASE, most likely on some other releases as well. I did not find any references to the evil ~/.login_conf{,.db} anywhere else in the source except in lib/libutil/login_cap.c. 1. Save the attached login_cap.c.diff in /tmp 2. cd /usr/src/lib/libutil 3. patch < /tmp/login_cap.c.diff 4. make 5. make install 6. re-start any affected daemons: /etc/rc.d/sshd restart /etc/rc.d/ftpd restart The relevant files are /lib/libutil.* and /usr/lib/libutil.* if you build on one machine and distribute binaries to others. Re-start the relevant daemons at each machine after updating the libutil libraries. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ --1852024168-802663992-1281453942=:96753 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=login_cap.c.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: login_cap.c.diff Content-Disposition: attachment; filename=login_cap.c.diff LS0tIGxvZ2luX2NhcC5jLm9yaWcJMjAxMC0wNi0xNCAwMjowOTowNi4wMDAw MDAwMDAgKzAwMDANCisrKyBsb2dpbl9jYXAuYwkyMDEwLTA4LTEwIDE0OjU1 OjEzLjAwMDAwMDAwMCArMDAwMA0KQEAgLTE5NCwxMSArMTk0LDEzIEBADQog CWludCAgICAgICAgIHIsIG1lLCBpID0gMDsNCiAJdWlkX3QgZXVpZCA9IDA7 DQogCWdpZF90IGVnaWQgPSAwOw0KIAljb25zdCBjaGFyICAqbXNnID0gTlVM TDsNCiAJY29uc3QgY2hhciAgKmRpcjsNCisjaWZkZWYgWFhYX1VTRVJfTE9H SU5fQ09ORl9FTkFCTEVEDQogCWNoYXIJICAgIHVzZXJwYXRoW01BWFBBVEhM RU5dOw0KKyNlbmRpZg0KIA0KIAlzdGF0aWMgY2hhciAqbG9naW5fZGJhcnJh eVtdID0geyBOVUxMLCBOVUxMLCBOVUxMIH07DQogDQogCW1lID0gKG5hbWUg IT0gTlVMTCAmJiBzdHJjbXAobmFtZSwgTE9HSU5fTUVDTEFTUykgPT0gMCk7 DQogCWRpciA9ICghbWUgfHwgcHdkID09IE5VTEwpID8gTlVMTCA6IHB3ZC0+ cHdfZGlyOw0KQEAgLTIxMywxNSArMjE1LDE3IEBADQogCSAgICBlZ2lkID0g Z2V0ZWdpZCgpOw0KIAkgICAgKHZvaWQpc2V0ZWdpZChwd2QtPnB3X2dpZCk7 DQogCSAgICAodm9pZClzZXRldWlkKHB3ZC0+cHdfdWlkKTsNCiAJfQ0KIA0K KyNpZmRlZiBYWFhfVVNFUl9MT0dJTl9DT05GX0VOQUJMRUQNCiAJaWYgKGRp ciAmJiBzbnByaW50Zih1c2VycGF0aCwgTUFYUEFUSExFTiwgIiVzLyVzIiwg ZGlyLA0KIAkJCSAgICBfRklMRV9MT0dJTl9DT05GKSA8IE1BWFBBVEhMRU4p IHsNCiAJICAgIGlmIChfc2VjdXJlX3BhdGgodXNlcnBhdGgsIHB3ZC0+cHdf dWlkLCBwd2QtPnB3X2dpZCkgIT0gLTEpDQogCQlsb2dpbl9kYmFycmF5W2kr K10gPSB1c2VycGF0aDsNCiAJfQ0KKyNlbmRpZg0KIAkvKg0KIAkgKiBYWFg6 IFdoeSB0byBhZGQgdGhlIHN5c3RlbSBkYXRhYmFzZSBpZiB0aGUgY2xhc3Mg aXMgYG1lJz8NCiAJICovDQogCWlmIChfc2VjdXJlX3BhdGgocGF0aF9sb2dp bl9jb25mLCAwLCAwKSAhPSAtMSkNCiAJICAgIGxvZ2luX2RiYXJyYXlbaSsr XSA9IHBhdGhfbG9naW5fY29uZjsNCg== --1852024168-802663992-1281453942=:96753-- From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 15:27:43 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 00FED1065674 for ; Tue, 10 Aug 2010 15:27:43 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B85AE8FC19 for ; Tue, 10 Aug 2010 15:27:42 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 752CD1FFC36; Tue, 10 Aug 2010 15:10:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 44A3B84525; Tue, 10 Aug 2010 17:10:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Janne Snabb References: Date: Tue, 10 Aug 2010 17:10:14 +0200 In-Reply-To: (Janne Snabb's message of "Tue, 10 Aug 2010 09:33:15 +0000 (UTC)") Message-ID: <86aaou4i7d.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: ~/.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 15:27:43 -0000 Janne Snabb writes: > This looks a bit worrying: > > http://lists.grok.org.uk/pipermail/full-disclosure/2010-August/075944.html It would be easier to take this seriously if it didn't come from a script kiddie who clearly does not understand the tools he's using. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 15:36:14 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 5B39E106566B for ; Tue, 10 Aug 2010 15:36:14 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1E36A8FC1F for ; Tue, 10 Aug 2010 15:36:13 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 283031FFC33; Tue, 10 Aug 2010 15:36:13 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E800184525; Tue, 10 Aug 2010 17:36:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Przemyslaw Frasunek References: <4C611FA9.6070409@frasunek.com> Date: Tue, 10 Aug 2010 17:36:12 +0200 In-Reply-To: <4C611FA9.6070409@frasunek.com> (Przemyslaw Frasunek's message of "Tue, 10 Aug 2010 11:45:13 +0200") Message-ID: <86fwym32fn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: ~/.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 15:36:14 -0000 Przemyslaw Frasunek 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=3Dnobody. Janne's mistake is to assume that reading =3D=3D 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 15:55:02 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 800E11065749 for ; Tue, 10 Aug 2010 15:55:02 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1B18FC1B for ; Tue, 10 Aug 2010 15:55:01 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 0989E151A59; Tue, 10 Aug 2010 18:39:28 +0300 (EEST) Date: Tue, 10 Aug 2010 18:39:28 +0300 From: Jaakko Heinonen To: Janne Snabb Message-ID: <20100810153928.GA28619@jh> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Tue, 10 Aug 2010 15:59:26 +0000 Cc: freebsd-security@freebsd.org Subject: Re: ~/.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 15:55:02 -0000 On 2010-08-10, Janne Snabb wrote: > Looks like the per-user login capability database (~/.login_conf, > ~/.login_conf.db) functionality is creating a vulnerability. See also PR bin/141840: http://www.freebsd.org/cgi/query-pr.cgi?pr=141840 -- Jaakko From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 18:13:39 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 4B1A2106566C for ; Tue, 10 Aug 2010 18:13:39 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 891E58FC14 for ; Tue, 10 Aug 2010 18:13:38 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o7AHrOvw064366; Wed, 11 Aug 2010 00:53:24 +0700 (NOVST) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.4/8.14.4/Submit) id o7AHrOPr064365; Wed, 11 Aug 2010 00:53:24 +0700 (NOVST) (envelope-from eugen) Date: Wed, 11 Aug 2010 00:53:24 +0700 From: Eugene Grosbein To: Dag-Erling Sm??rgrav Message-ID: <20100810175323.GA63364@rdtc.ru> References: <4C611FA9.6070409@frasunek.com> <86fwym32fn.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86fwym32fn.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Tue, 10 Aug 2010 18:26:40 +0000 Cc: freebsd-security@freebsd.org, Przemyslaw Frasunek Subject: Re: ~/.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 18:13:39 -0000 On Tue, Aug 10, 2010 at 05:36:12PM +0200, Dag-Erling Sm??rgrav wrote: > > 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. There is another issue in stock ftpd and usercontext, see PR http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/143570 which contains trivial patch. Eugene Grosbein From owner-freebsd-security@FreeBSD.ORG Tue Aug 10 21:02:03 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 810E810656B5 for ; Tue, 10 Aug 2010 21:02:03 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 428748FC20 for ; Tue, 10 Aug 2010 21:02:03 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 48D661FFC33; Tue, 10 Aug 2010 21:02:02 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 12A7F8455C; Tue, 10 Aug 2010 23:02:02 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Eugene Grosbein References: <4C611FA9.6070409@frasunek.com> <86fwym32fn.fsf@ds4.des.no> <20100810175323.GA63364@rdtc.ru> Date: Tue, 10 Aug 2010 23:02:01 +0200 In-Reply-To: <20100810175323.GA63364@rdtc.ru> (Eugene Grosbein's message of "Wed, 11 Aug 2010 00:53:24 +0700") Message-ID: <86tyn2npva.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Przemyslaw Frasunek Subject: Re: ~/.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 21:02:03 -0000 Eugene Grosbein writes: > There is another issue in stock ftpd and usercontext, > see PR http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/143570 > which contains trivial patch. Mostly unrelated, but interesting nonetheless. Thank you. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Aug 12 13:02:17 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 9B31010656A5 for ; Thu, 12 Aug 2010 13:02:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 55D868FC1D for ; Thu, 12 Aug 2010 13:02:17 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7CD2Ckv024674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 09:02:12 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7CD2BJv044208 for ; Thu, 12 Aug 2010 09:02:11 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008121302.o7CD2BJv044208@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Aug 2010 09:02:19 -0400 To: freebsd-security@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Subject: Re: ~/.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: Thu, 12 Aug 2010 13:02:17 -0000 Are there any other tricks / work around people have implemented ? MACs ? ---Mike At 11:25 AM 8/10/2010, Janne Snabb wrote: >On Tue, 10 Aug 2010, Janne Snabb wrote: > > > Looks like the per-user login capability database (~/.login_conf, > > ~/.login_conf.db) functionality is creating a vulnerability. > >Attached is a temporary workaround for anyone who is worried about >this problem. It disables per-user login capability databases >completely. Only the system wide /etc/login.conf is used. Do not >apply the patch if you need per-user login capabilities. > >This should work on 8.1-RELEASE, most likely on some other releases >as well. I did not find any references to the evil ~/.login_conf{,.db} >anywhere else in the source except in lib/libutil/login_cap.c. > >1. Save the attached login_cap.c.diff in /tmp > >2. cd /usr/src/lib/libutil > >3. patch < /tmp/login_cap.c.diff > >4. make > >5. make install > >6. re-start any affected daemons: > /etc/rc.d/sshd restart > /etc/rc.d/ftpd restart > >The relevant files are /lib/libutil.* and /usr/lib/libutil.* if you >build on one machine and distribute binaries to others. Re-start >the relevant daemons at each machine after updating the libutil >libraries. > >-- >Janne Snabb / EPIPE Communications >snabb@epipe.com - http://epipe.com/ > >_______________________________________________ >freebsd-security@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-security >To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-security@FreeBSD.ORG Thu Aug 12 19:01:40 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 0108510656A7 for ; Thu, 12 Aug 2010 19:01:40 +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 94F328FC18 for ; Thu, 12 Aug 2010 19:01:39 +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 o7CJ1cj4044635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2010 19:01:38 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com o7CJ1cj4044635 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1281639699; x=1282244499; bh=XGMMSIBaks1XzmVQ1QCK/+IQWw86iSeSGwKni9YVBjE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=DG3yfwu8DPcUxPa25uAsFFChubr1+xiR3ZT5CHwCVq2HXFRT0TRvFq44hx1anrzBO vj3TXdV8ojqTKtQDtXPAh0dP1j814n1Khs7gyYGn/BVZ5t5swMS7uwploa/6yfJaz1 0DUh5fGnQE5hZ+8UUtnH98B2+7EADo1UqhQVhymY= Date: Thu, 12 Aug 2010 19:01:38 +0000 (UTC) From: Janne Snabb To: Mike Tancsa In-Reply-To: <201008121302.o7CD2BJv044208@lava.sentex.ca> Message-ID: References: <201008121302.o7CD2BJv044208@lava.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org Subject: Re: ~/.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: Thu, 12 Aug 2010 19:01:40 -0000 On Thu, 12 Aug 2010, Mike Tancsa wrote: > Are there any other tricks / work around people have implemented ? MACs ? Binary patch libutil: 1. cd /lib 2. perl -pi.bak -e 's!\.login_conf!../.noexist!;' libutil.so.* 3. /etc/rc.d/sshd restart ; /etc/rc.d/ftpd restart The above binary patch makes the login procedure to look for a file called ".noexist" one level up from the user's home directory. If that directory is not writable by the user (as is typically), the patch will protect you from the potential vulnerability (by disabling user-specific capabilities processing). (Yes, you can use perl regular expressions to do binary patches. They do not seem to break anything in the binary data. I have been doing similar things for years. sed is not robust for this purpose. Obviously you will break everything if the replacement string is not of the same length as the original.) I was looking at the lib/libc/db code today for some time. valgrind reports several out-of-allocated-space accesses when db functions are given a malicious .db file (__getbuf_crash_suspicious.db from HI-TECH's mail attachment for example). The code is somewhat complicated to understand, as I am not familiar with it, thus no real solution (from me at least). -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From owner-freebsd-security@FreeBSD.ORG Fri Aug 13 04:35:18 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 7E1C610656AB; Fri, 13 Aug 2010 04:35:18 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5941C8FC20; Fri, 13 Aug 2010 04:35:18 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EAC5C46B7F; Fri, 13 Aug 2010 00:35:17 -0400 (EDT) Date: Fri, 13 Aug 2010 05:35:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: trustedbsd-discuss@TrustedBSD.org, freebsd-security@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Capsicum: practical capabilities for UNIX (fwd) 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: Fri, 13 Aug 2010 04:35:18 -0000 For those following security and access control in FreeBSD, this may be of interest. We'll have updated patches for Capsicum available for FreeBSD 8.1 in the next week or so. Feedback on the approach would be most welcome! Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Thu, 12 Aug 2010 03:00:03 -0000 From: Light Blue Touchpaper Reply-To: cl-security-research@lists.cam.ac.uk To: cl-security-research@lists.cam.ac.uk Subject: Capsicum: practical capabilities for UNIX URL: http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/ by Robert N. M. Watson Today, Jonathan Anderson, Ben Laurie, Kris Kennaway, and I presented [Capsicum: practical capabilities for UNIX][1] at the [19th USENIX Security Symposium][2] in Washington, DC; the [slides][3] can be found on the [Capsicum web site][4]. We argue that capability design principles fill a gap left by discretionary access control (DAC) and mandatory access control (MAC) in operating systems when supporting security-critical and security-aware applications. Capsicum responds to the trend of application compartmentalisation (sometimes called privilege separation) by providing strong and well-defined isolation primitives, and by facilitating rights delegation driven by the application (and eventually, user). These facilities prove invaluable, not just for traditional security-critical programs such as tcpdump and OpenSSH, but also complex security-aware applications that map distributed security policies into local primitives, such as Google's Chromium web browser, which implement the same- origin policy when sandboxing JavaScript execution. Capsicum extends POSIX with a new _capability mode_ for processes, and _capability_ file descriptor type, as well as supporting primitives such as _process descriptors_. Capability mode denies access to global operating system namespaces, such as the file system and IPC namespaces: only delegated rights (typically via file descriptors or more refined capabilities) are available to sandboxes. We prototyped Capsicum on FreeBSD 9.x, and have extended a variety of applications, including Google's Chromium web browser, to use Capsicum for sandboxing. Our paper discusses design trade-offs, both in Capsicum and in applications, as well as a performance analysis. Capsicum is available under a BSD license. Capsicum is collaborative research between the University of Cambridge and Google, and has been sponsored by Google, and will be a foundation for future work on application security, sandboxing, and usability security at Cambridge and Google. Capsicum has also been backported to FreeBSD 8.x, and Heradon Douglas at Google has an in-progress port to Linux. We're also pleased to report the Capsicum paper won Best Student Paper award at the conference! [1]: http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix- security-capsicum-website.pdf [2]: http://www.usenix.org/events/sec10/ [3]: http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811 -usenix-capsicum.pdf [4]: http://www.cl.cam.ac.uk/research/security/capsicum/ From owner-freebsd-security@FreeBSD.ORG Fri Aug 13 05:34: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 BA8A71065694 for ; Fri, 13 Aug 2010 05:34:16 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B16A8FC14 for ; Fri, 13 Aug 2010 05:34:16 +0000 (UTC) Received: by gwj23 with SMTP id 23so939975gwj.13 for ; Thu, 12 Aug 2010 22:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9t/3mbIGbvXxJUJVC2AG+dajfRrG+4NW8hXEUGLXr/E=; b=tv8ZAPy8z/15CeKE5Gimw8X0KD4XG0SMcxgHEXIvJiqWMBfHIB5ZArLkre8VPC2eB7 D/vysqOwqCl0yF5OSTo3HAyA8RRw7coxl4AK0XqLcaSTUeUu0wwLc8K3EL8jC9eEOLJr nG8V/O9yt5KUhL77v15pQiz31+I0UtiWjhCck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gpkQnnpnwYzCi+Av3XAl7Y+mSTzqw5fJrGzoUrLt7ntaPLobIIiHemSR6THxiQ15AL mCU9J3zSxoqK6iTNszz7KGt9FLdHqHzWL0HVViDzvANWd2mTOgNe1FjJ+9XlrX8gF9AQ 4DRWIC98uMEyyOdYTLt4pekvcu2VSqMIJhkkc= Received: by 10.100.119.14 with SMTP id r14mr1247998anc.156.1281675762939; Thu, 12 Aug 2010 22:02:42 -0700 (PDT) Received: from centel.dataix.local ([99.19.46.227]) by mx.google.com with ESMTPS id c6sm3533839anj.31.2010.08.12.22.02.40 (version=SSLv3 cipher=RC4-MD5); Thu, 12 Aug 2010 22:02:41 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C64D1EF.6030508@dataix.net> Date: Fri, 13 Aug 2010 01:02:39 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Janne Snabb References: <201008121302.o7CD2BJv044208@lava.sentex.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: ~/.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: Fri, 13 Aug 2010 05:34:16 -0000 On 08/12/2010 15:01, Janne Snabb wrote: > On Thu, 12 Aug 2010, Mike Tancsa wrote: > >> Are there any other tricks / work around people have implemented ? MACs ? > > Binary patch libutil: > > 1. cd /lib > > 2. perl -pi.bak -e 's!\.login_conf!../.noexist!;' libutil.so.* > > 3. /etc/rc.d/sshd restart ; /etc/rc.d/ftpd restart > > The above binary patch makes the login procedure to look for a file > called ".noexist" one level up from the user's home directory. If > that directory is not writable by the user (as is typically), the > patch will protect you from the potential vulnerability (by disabling > user-specific capabilities processing). > > (Yes, you can use perl regular expressions to do binary patches. > They do not seem to break anything in the binary data. I have been > doing similar things for years. sed is not robust for this purpose. > Obviously you will break everything if the replacement string is > not of the same length as the original.) > > I was looking at the lib/libc/db code today for some time. valgrind > reports several out-of-allocated-space accesses when db functions > are given a malicious .db file (__getbuf_crash_suspicious.db from > HI-TECH's mail attachment for example). The code is somewhat > complicated to understand, as I am not familiar with it, thus no > real solution (from me at least). > > -- > Janne Snabb / EPIPE Communications > snabb@epipe.com - http://epipe.com/ Very nice and easy way to patch & a great suggestion. On the note of using a ~/.login_conf file for setting limits and in this case increasing them. when they shouldn't be. I have been using a ~/.login_conf without generating the ~/.login_conf.db through the use of cap_mkdb(1) for quite some time. So on that, is it really necessary to look for that .db file at all since ~/.login_conf works without it... Regards, -- jhell,v From owner-freebsd-security@FreeBSD.ORG Fri Aug 13 09:15:45 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 2913510656A7; Fri, 13 Aug 2010 09:15:45 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.213.67.47]) by mx1.freebsd.org (Postfix) with ESMTP id EC1928FC1A; Fri, 13 Aug 2010 09:15:44 +0000 (UTC) Received: from localhost (unknown [172.16.100.24]) by mail.barafranca.com (Postfix) with ESMTP id 6B6F89B7; Fri, 13 Aug 2010 09:02:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at barafranca.com Received: from mail.barafranca.com ([172.16.100.24]) by localhost (mail.barafranca.com [172.16.100.24]) (amavisd-new, port 10024) with ESMTP id xjDDt1sOptK0; Fri, 13 Aug 2010 09:01:48 +0000 (UTC) Received: from [10.100.2.100] (a94-132-9-136.cpe.netcabo.pt [94.132.9.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTPSA id 4EB439B2; Fri, 13 Aug 2010 09:01:47 +0000 (UTC) Message-ID: <4C650A01.5070002@barafranca.com> Date: Fri, 13 Aug 2010 10:01:53 +0100 From: Hugo Silva User-Agent: Thunderbird 2.0.0.23 (X11/20091030) MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org Subject: Re: Capsicum: practical capabilities for UNIX (fwd) 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: Fri, 13 Aug 2010 09:15:45 -0000 Robert Watson wrote: > > For those following security and access control in FreeBSD, this may be > of interest. We'll have updated patches for Capsicum available for > FreeBSD 8.1 in the next week or so. Feedback on the approach would be > most welcome! > > Robert N M Watson > Computer Laboratory > University of Cambridge Very nice. I am looking forward to play with this ;-) > > ---------- Forwarded message ---------- > Date: Thu, 12 Aug 2010 03:00:03 -0000 > From: Light Blue Touchpaper > Reply-To: cl-security-research@lists.cam.ac.uk > To: cl-security-research@lists.cam.ac.uk > Subject: Capsicum: practical capabilities for UNIX > > URL: > http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/ > > by Robert N. M. Watson > > Today, Jonathan Anderson, Ben Laurie, Kris Kennaway, and I presented > [Capsicum: > practical capabilities for UNIX][1] at the [19th USENIX Security > Symposium][2] > in Washington, DC; the [slides][3] can be found on the [Capsicum web > site][4]. > We argue that capability design principles fill a gap left by discretionary > access control (DAC) and mandatory access control (MAC) in operating > systems > when supporting security-critical and security-aware applications. > > Capsicum responds to the trend of application compartmentalisation > (sometimes > called privilege separation) by providing strong and well-defined isolation > primitives, and by facilitating rights delegation driven by the > application (and > eventually, user). These facilities prove invaluable, not just for > traditional > security-critical programs such as tcpdump and OpenSSH, but also complex > security-aware applications that map distributed security policies into > local > primitives, such as Google's Chromium web browser, which implement the > same- > origin policy when sandboxing JavaScript execution. > > Capsicum extends POSIX with a new _capability mode_ for processes, and > _capability_ file descriptor type, as well as supporting primitives such as > _process descriptors_. Capability mode denies access to global operating > system > namespaces, such as the file system and IPC namespaces: only delegated > rights > (typically via file descriptors or more refined capabilities) are > available to > sandboxes. We prototyped Capsicum on FreeBSD 9.x, and have extended a > variety of > applications, including Google's Chromium web browser, to use Capsicum for > sandboxing. Our paper discusses design trade-offs, both in Capsicum and in > applications, as well as a performance analysis. Capsicum is available > under a > BSD license. > > Capsicum is collaborative research between the University of Cambridge and > Google, and has been sponsored by Google, and will be a foundation for > future > work on application security, sandboxing, and usability security at > Cambridge > and Google. Capsicum has also been backported to FreeBSD 8.x, and Heradon > Douglas at Google has an in-progress port to Linux. > > We're also pleased to report the Capsicum paper won Best Student Paper > award at > the conference! > > [1]: > http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix- > security-capsicum-website.pdf > > [2]: http://www.usenix.org/events/sec10/ > > [3]: http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811 > -usenix-capsicum.pdf > > [4]: http://www.cl.cam.ac.uk/research/security/capsicum/ > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Fri Aug 13 10:35:18 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 D13C9106566B for ; Fri, 13 Aug 2010 10:35:18 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9007C8FC1E for ; Fri, 13 Aug 2010 10:35:18 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AD42B1FFC36; Fri, 13 Aug 2010 10:35:17 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 77A3B8454E; Fri, 13 Aug 2010 12:35:17 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: jhell References: <201008121302.o7CD2BJv044208@lava.sentex.ca> <4C64D1EF.6030508@dataix.net> Date: Fri, 13 Aug 2010 12:35:17 +0200 In-Reply-To: <4C64D1EF.6030508@dataix.net> (jhell@dataix.net's message of "Fri, 13 Aug 2010 01:02:39 -0400") Message-ID: <86r5i2ssuy.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Janne Snabb Subject: Re: ~/.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: Fri, 13 Aug 2010 10:35:18 -0000 jhell writes: > On the note of using a ~/.login_conf file for setting limits and in this > case increasing them. when they shouldn't be. > > I have been using a ~/.login_conf without generating the > ~/.login_conf.db through the use of cap_mkdb(1) for quite some time. So > on that, is it really necessary to look for that .db file at all since > ~/.login_conf works without it... It won't make any difference. The problem is that setusercontext() applies the user's settings even if it's still running as root. I have a patch, but I need to check that it doesn't break anything. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sat Aug 14 12:15:05 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 D8955106566C for ; Sat, 14 Aug 2010 12:15:05 +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 752278FC23 for ; Sat, 14 Aug 2010 12:15:05 +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 o7ECF0HI073372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Aug 2010 12:15:00 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com o7ECF0HI073372 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1281788100; x=1282392900; bh=3S+Jf0YqnTkUKeO0ZvmixdnVJ/anQgdEbH5l5s5hFKk=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=P0H6dNJ+Z4IDrPUwLTL27RKShl0PnqmJqhFxjpGxl2pLz4+CXw+NFGIrMHM/r8ruO vUWFryDXvzKuBNjV1aEmqmDgnzkRrXCeS/lN7dXfIdHzHKMhimCdyoQRIkLr5ILrRO WmsVPM8pNKWtr2POcMHewhHPa8Ksl8UBBzJ8YUBQ= Date: Sat, 14 Aug 2010 12:15:00 +0000 (UTC) From: Janne Snabb To: jhell In-Reply-To: <4C64D1EF.6030508@dataix.net> Message-ID: References: <201008121302.o7CD2BJv044208@lava.sentex.ca> <4C64D1EF.6030508@dataix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org Subject: Re: ~/.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: Sat, 14 Aug 2010 12:15:06 -0000 On Fri, 13 Aug 2010, jhell wrote: > I have been using a ~/.login_conf without generating the > ~/.login_conf.db through the use of cap_mkdb(1) for quite some time. So > on that, is it really necessary to look for that .db file at all since > ~/.login_conf works without it... This change would require some API changes or changing the way some things work. The relevant generic *cap interface in lib/libc/gen/getcap.c uses the .db files unconditionally instead of text files if they exist. This is used for login capabilities, terminal capabilities and some other things. Do we need a DB backend for these things, is it unfeasible to just always parse the text files? To me it would appear that the system DB storage engine (Berkeley DB 1.85 with some improvements) should be deprecated and replaced with something else. Keith Bostic wrote the following in 2004: > Nobody supports or maintains the 1.85 or 1.86 releases of > Berkeley DB, the code base has been ignored for almost a decade. > (Further, there are serious known problems with the 1.85/1.86 > versions, including some that can only be fixed by modifying the > on-disk format.) The following thread also touches the topic of DB 1.85 reliability: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024425.html It appears that the Mozilla project has an improved version of the hash part of the DB code as they use it as a certificate store. The code seems to have some changes to make it more robust. It resides in "dbm" sub-directory of firefox source distribution and here: http://mxr.mozilla.org/security/source/dbm/ . Importing those improvements to FreeBSD would make sense if we *must* keep using the deprecated Berkeley DB code. Opinions? Is it finally time to switch to something else? Are there any viable alternatives which provide compatible simple interface, simple file format and robustness, with a suitable license? -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From owner-freebsd-security@FreeBSD.ORG Sat Aug 14 19:19:49 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 9AFE410656D7 for ; Sat, 14 Aug 2010 19:19:49 +0000 (UTC) (envelope-from robert.watson@cl.cam.ac.uk) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 552C88FC1A for ; Sat, 14 Aug 2010 19:19:49 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CA51346B86; Sat, 14 Aug 2010 15:19:48 -0400 (EDT) Date: Sat, 14 Aug 2010 20:19:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hugo Silva In-Reply-To: <4C650A01.5070002@barafranca.com> Message-ID: References: <4C650A01.5070002@barafranca.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 14 Aug 2010 21:16:36 +0000 Cc: freebsd-security@FreeBSD.org Subject: Re: Capsicum: practical capabilities for UNIX (fwd) 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: Sat, 14 Aug 2010 19:19:49 -0000 On Fri, 13 Aug 2010, Hugo Silva wrote: >> For those following security and access control in FreeBSD, this may be of >> interest. We'll have updated patches for Capsicum available for FreeBSD >> 8.1 in the next week or so. Feedback on the approach would be most >> welcome! > > Very nice. I am looking forward to play with this ;-) Thanks! Right now our prototype is against a month or so old 9-CURRENT, with a somewhat more recent 8.x snapshot. Several of us are on travel now but with any luck we can do a set of patches against a vanilla 8.1 later in the month. The merge plan for 9.x isn't determined yet, we have a number of issues that need to be worked through, including a few missing features and more extensive test suites. For those that are interested in lending a hand as early adopters, we have a Capsicum mailing list which can be subscribed to via our web page: http://www.cl.cam.ac.uk/research/security/capsicum/ This work is increasingly ready to get attention from folks other than us! Robert > >> >> ---------- Forwarded message ---------- >> Date: Thu, 12 Aug 2010 03:00:03 -0000 >> From: Light Blue Touchpaper >> Reply-To: cl-security-research@lists.cam.ac.uk >> To: cl-security-research@lists.cam.ac.uk >> Subject: Capsicum: practical capabilities for UNIX >> >> URL: >> http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/ >> by Robert N. M. Watson >> >> Today, Jonathan Anderson, Ben Laurie, Kris Kennaway, and I presented >> [Capsicum: >> practical capabilities for UNIX][1] at the [19th USENIX Security >> Symposium][2] >> in Washington, DC; the [slides][3] can be found on the [Capsicum web >> site][4]. >> We argue that capability design principles fill a gap left by discretionary >> access control (DAC) and mandatory access control (MAC) in operating >> systems >> when supporting security-critical and security-aware applications. >> >> Capsicum responds to the trend of application compartmentalisation >> (sometimes >> called privilege separation) by providing strong and well-defined isolation >> primitives, and by facilitating rights delegation driven by the application >> (and >> eventually, user). These facilities prove invaluable, not just for >> traditional >> security-critical programs such as tcpdump and OpenSSH, but also complex >> security-aware applications that map distributed security policies into >> local >> primitives, such as Google's Chromium web browser, which implement the >> same- >> origin policy when sandboxing JavaScript execution. >> >> Capsicum extends POSIX with a new _capability mode_ for processes, and >> _capability_ file descriptor type, as well as supporting primitives such as >> _process descriptors_. Capability mode denies access to global operating >> system >> namespaces, such as the file system and IPC namespaces: only delegated >> rights >> (typically via file descriptors or more refined capabilities) are available >> to >> sandboxes. We prototyped Capsicum on FreeBSD 9.x, and have extended a >> variety of >> applications, including Google's Chromium web browser, to use Capsicum for >> sandboxing. Our paper discusses design trade-offs, both in Capsicum and in >> applications, as well as a performance analysis. Capsicum is available >> under a >> BSD license. >> >> Capsicum is collaborative research between the University of Cambridge and >> Google, and has been sponsored by Google, and will be a foundation for >> future >> work on application security, sandboxing, and usability security at >> Cambridge >> and Google. Capsicum has also been backported to FreeBSD 8.x, and Heradon >> Douglas at Google has an in-progress port to Linux. >> >> We're also pleased to report the Capsicum paper won Best Student Paper >> award at >> the conference! >> >> [1]: >> http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix- >> security-capsicum-website.pdf >> >> [2]: http://www.usenix.org/events/sec10/ >> >> [3]: http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811 >> -usenix-capsicum.pdf >> >> [4]: http://www.cl.cam.ac.uk/research/security/capsicum/ >> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >