From owner-freebsd-security@FreeBSD.ORG Wed Mar 5 23:39:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D8EEDD5; Wed, 5 Mar 2014 23:39:05 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E695D67; Wed, 5 Mar 2014 23:39:05 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 7688616157; Wed, 5 Mar 2014 15:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394062744; bh=uZKvk7jClgl/Nt5YZcwtNcpoHPV3sDD/lhzjS5Z/SXg=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=2QnLeXEDJYkqTnvqFUStk23dCNFibl5ClSZXhwIbHsMorSOfrywCyPZa+asF8wKQM Pw+uylck8CDKuvlfmOPX+Eb5YjJG6HwZJ6ncgK2XxIEh2Cy8nHv8PY6UAnDdEs478h qygkb6cGE1j3j8hDbIpWEr5hGvsWigruHV5YSBpw= Message-ID: <5317B597.5050900@delphij.net> Date: Wed, 05 Mar 2014 15:39:03 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Nicola Galante , freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> In-Reply-To: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" , jamie@FreeBSD.org, "secteam@FreeBSD.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 23:39:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/05/14 15:07, Nicola Galante wrote: > I found a potential vulnerability with FreeBSD jails. I installed a > server (hostserver) for my institute. This hostserver has a certain > IP address, let's say 10.0.0.100, and I installed and configured > three service jails (elog, mail, www), each with a different IP > address (10.0.0.101, 10.0.0.102, 10.0.0.103) > > root@hostserver:/jails/j # jls JID IP Address Hostname > Path 1 10.0.0.101 elogjail /jails/j/elog 2 > 10.0.0.102 mailjail /jails/j/mail 3 > 10.0.0.103 wwwjail /jails/j/www > > I have an account on both the hostserver and the elogjail. Password > authentication on hostserver and ssh key authentication in the > jail. The service sshd is running on both the hostserver and > elogjail. If I ssh into the elogjail > > [galante@caronte ~]$ ssh galante@elogjail Enter passphrase for key > '/home/galante/.ssh/id_dsa': Last login: Wed Mar 5 21:37:23 2014 > from caronte galante@elogjail:~ % > > as expected. But if I turn off the sshd service in elogjail (and > keep the elogjail up and running) and I try to connect to elogjail, > I first get a complaint that the fingerprint for the RSA key sent > by the remote host has changed. If I remove the corresponding line > in my local .ssh/known_hosts file and try to reconnect, this is > what happens: > > [galante@caronte ~]$ ssh galante@elogjail Password for > galante@hostserver: Last login: Wed Mar 5 21:12:20 2014 from > caronte galante@hostserver:~ % > > I log into the host system! Of course this is possible because I > have an account on both the host system and the jail. However, I > believe that this can cause a serious potential security threat. I > can envision several scenarios where somebody attempts to get into > a jail and instead gets into the host system. I checked also the > DNS responsiveness. The problem persists even if I use IP addresses > instead of host names. >> How-To-Repeat: > Follow the steps described above. >> Fix: > I don't know how to fix the problem other than by disabling sshd in > the hostserver. I don't think this is a security issue and close this as invalid, however I'm bringing secteam@ and jamie@ in, just to make sure I didn't understood the problem wrong. The first thing is let's confirm that I'm understanding your question correctly. What happens is that: a) you have account on *both* jail and host system. b) you attempted to log in into jail's IP, which is also bound to host system; c) your configuration didn't explicitly specify SSH's listening address on host, so it's a wildcard (Listen 22 instead of Listen hostip:22, where you can see in sockstat -4l as *:22 for sshd). and d) when jail is shut down, when you connect to the jail's IP, you connected into the host. This is NOT a problem with jail. For starters, it's very bad idea to give out host shell account, privileged or not, to jail users if they are not trusted. Let's consider this scenario: jail$ su -l jail# cp /usr/bin/less /bin/root_shell jail# chown root:wheel /bin/root_shell jail# chmod 6555 /bin/root_shell jail# logout jail$ logout Then, you basically have a setuid binary that can be reached from host system. As an attacker I would do: host$ /path/to/jail/bin/root_shell # So the solution would be to change your configuration such that: 1) Do not give shell access to jail users unless they are also host system administrator. 2) Do not make host's sshd to listen on all addresses, instead, only listen to the designated host IP address. This is not a security measure but avoids confusion. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTF7WXAAoJEJW2GBstM+ns/dMP/2MdcY2FbXR7nl5cc5NL6Xyi O87+Eee5QbJ4pRP/CdvTD4OivHi8BecS9egQDhtRuIvv6XtHWCD26KPuMUYgZd4U 8min9L/kfFLwlBIuH9CKGR0iRzXDGY99NpRVpwSJBPxSeJrUZZzCMdoCwEQPvhkQ S4TNv9+qiXmqDAwJbcTFDUfhqc9FPuaLfdn/6+Cbi3MEAhJjaAuuvbZeUvhKLi/n xavs3e9tqcy3i3D6dJvSuOvDibBbrLpamch23VeyOMTZ78ahOKLa5dDAfkFJgx+g JicfTcdcSiPEutPenJo1bWUn5DbW1+aoNL+acBLty9Q0iknn8dcSG6PWDHnz3pmq +hE8lOq+7HGkVoqIGtDULlPy2eEeM6WwjUj4wcAQI7PfStkTc7eqJooj76mMmPg7 CKF0yaqAG/57Qys4G6eVRxW8sAV33k8gaeTjjrRX6tFYZvZElSZ57shxZPinxzQe XAAyq2E1gkxKnnvFZGEJSv4kmyE0u4jJAGW17N3x04R/VjPgtdBKZ4YeG3HoHdh3 vJ9LBUuZvx3zy0bVslJFKTNQq3tvCWhOkf4dITHKm2JBpaeo9VwGs50yUKYg/3NB //NDUnQCF9rpoqU40w9JKEOiWO+nZLUzdXLerI8TccU15Mz0dpo+06oC6e72DVtG aUQS8DKHmWB9SwgXX02d =ky3s -----END PGP SIGNATURE-----