From owner-freebsd-bugs@FreeBSD.ORG Thu Mar 6 13:21:57 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B22CB55 for ; Thu, 6 Mar 2014 13:21:57 +0000 (UTC) Received: from chibanda.earlham.edu (chibanda.earlham.edu [159.28.1.168]) by mx1.freebsd.org (Postfix) with ESMTP id 492021F8 for ; Thu, 6 Mar 2014 13:21:57 +0000 (UTC) X-ASG-Debug-ID: 1394111341-06e52b0b23414660001-rqrMvB Received: from sunstone.earlham.edu (sunstone.earlham.edu [159.28.3.91]) by chibanda.earlham.edu with ESMTP id mKNEbXRAxKackOaX; Thu, 06 Mar 2014 08:09:01 -0500 (EST) X-Barracuda-Envelope-From: schulra@earlham.edu X-Barracuda-Apparent-Source-IP: 159.28.3.91 Received: from tdream.lly.earlham.edu (tdream.lly.earlham.edu [159.28.7.241]) by sunstone.earlham.edu (Postfix) with ESMTP id 2727E171D530; Thu, 6 Mar 2014 08:09:01 -0500 (EST) Date: Thu, 6 Mar 2014 08:09:01 -0500 (EST) From: Randy Schultz X-X-Sender: schulra@localhost To: Nicola Galante Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail In-Reply-To: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> X-ASG-Orig-Subj: Re: misc/187307: Security vulnerability with FreeBSD Jail Message-ID: References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Barracuda-Connect: sunstone.earlham.edu[159.28.3.91] X-Barracuda-Start-Time: 1394111341 X-Barracuda-URL: http://159.28.1.168:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at earlham.edu X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:21:57 -0000 On Wed, 5 Mar 2014, 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. Set ssdh on hostserver to only listen on 10.0.0.100 should prevent this from happening. By default sshd listens on all addresses. -- Randy (schulra@earlham.edu) 765.983.1283 <*> Hatred does not cease by hatred, but only by love; this is the eternal rule. - Siddhartha Gautama