From nobody@FreeBSD.org  Wed Mar  5 23:07:23 2014
Return-Path: <nobody@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 AECBB7E
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  5 Mar 2014 23:07:23 +0000 (UTC)
Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.freebsd.org (Postfix) with ESMTPS id 80C82AF3
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  5 Mar 2014 23:07:23 +0000 (UTC)
Received: from cgiserv.freebsd.org ([127.0.1.6])
	by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s25N7NML045309
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 5 Mar 2014 23:07:23 GMT
	(envelope-from nobody@cgiserv.freebsd.org)
Received: (from nobody@localhost)
	by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s25N7NoD045308;
	Wed, 5 Mar 2014 23:07:23 GMT
	(envelope-from nobody)
Message-Id: <201403052307.s25N7NoD045308@cgiserv.freebsd.org>
Date: Wed, 5 Mar 2014 23:07:23 GMT
From: Nicola Galante <galante@veritas.sao.arizona.edu>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Security vulnerability with FreeBSD Jail
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         187307
>Category:       misc
>Synopsis:       Security vulnerability with FreeBSD Jail
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    delphij
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 05 23:10:00 UTC 2014
>Closed-Date:    Wed Mar 05 23:39:46 UTC 2014
>Last-Modified:  Thu Mar 20 12:40:01 UTC 2014
>Originator:     Nicola Galante
>Release:        10.0
>Organization:
Smithsonian Astrophysical Observatory
>Environment:
FreeBSD hostserver.localdomain 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
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.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: delphij 
State-Changed-When: Wed Mar 5 23:39:19 UTC 2014 
State-Changed-Why:  
Not a bug, please see my reply on freebsd-security@. 


Responsible-Changed-From-To: freebsd-bugs->delphij 
Responsible-Changed-By: delphij 
Responsible-Changed-When: Wed Mar 5 23:39:19 UTC 2014 
Responsible-Changed-Why:  
Take just in case I was wrong. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=187307 

From: Xin Li <delphij@delphij.net>
To: Nicola Galante <galante@veritas.sao.arizona.edu>, 
 freebsd-gnats-submit@FreeBSD.org
Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, 
 "secteam@FreeBSD.org" <secteam@FreeBSD.org>,
 jamie@FreeBSD.org
Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail
Date: Wed, 05 Mar 2014 15:39:03 -0800

 -----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 <delphij@delphij.net>    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-----

From: Scot Hetzel <swhetzel@gmail.com>
To: freebsd-gnats-submit@freebsd.org
Cc: Nicola Galante <galante@veritas.sao.arizona.edu>, 
	"freebsd-security@freebsd.org" <freebsd-security@freebsd.org>
Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail
Date: Wed, 5 Mar 2014 18:43:27 -0600

 On Wed, Mar 5, 2014 at 5:39 PM, Xin Li <delphij@delphij.net> wrote:
 > So the solution would be to change your configuration such that:
 >
 :
 > 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.
 >
 
 You will want to change the hosts sshd_config to only listen on the
 10.0.0.100 address:
 
 ListenAddress 10.0.0.100
 
 If the host needs to listen on multiple addresses, just add another
 ListenAddress.
 
 http://www.cyberciti.biz/tips/howto-openssh-sshd-listen-multiple-ip-address.html
 
 -- 
 DISCLAIMER:
 
 No electrons were maimed while sending this message. Only slightly bruised.

From: Jason Hellenthal <jhellenthal@dataix.net>
To: "d@delphij.net" <d@delphij.net>
Cc: Nicola Galante <galante@veritas.sao.arizona.edu>,
 "freebsd-gnats-submit@FreeBSD.org" <freebsd-gnats-submit@FreeBSD.org>,
 "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>,
 "jamie@FreeBSD.org" <jamie@FreeBSD.org>,
 "secteam@FreeBSD.org" <secteam@FreeBSD.org>
Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail
Date: Thu, 6 Mar 2014 01:55:11 -0500

 --Apple-Mail-B57BD488-AE1F-4C09-AEEE-4BF1170F2439
 Content-Type: multipart/alternative;
 	boundary=Apple-Mail-0F6E6005-A48F-492F-92E2-7CAB57D85559
 Content-Transfer-Encoding: 7bit
 
 
 --Apple-Mail-0F6E6005-A48F-492F-92E2-7CAB57D85559
 Content-Type: text/plain;
 	charset=us-ascii
 Content-Transfer-Encoding: quoted-printable
 
 I would also add  . . . separate ssh keys and passwords if the user needs ac=
 cess to both host and jailed systems. This is just common practice and not a=
  security flaw by any means but an engineering oversight.
 
 Popsicle sticks also have a security flaw, they let you jab yourself in the t=
 hroat if you fall while sucking on them. Solution . . . sit down.
 
 --=20
  Jason Hellenthal
  Voice: 95.30.17.6/616
  JJH48-ARIN
 
 > On Mar 5, 2014, at 18:39, Xin Li <delphij@delphij.net> wrote:
 >=20
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA512
 >=20
 >> 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)
 >>=20
 >> 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
 >>=20
 >> 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
 >>=20
 >> [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:~ %
 >>=20
 >> 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:
 >>=20
 >> [galante@caronte ~]$ ssh galante@elogjail Password for
 >> galante@hostserver: Last login: Wed Mar  5 21:12:20 2014 from
 >> caronte galante@hostserver:~ %
 >>=20
 >> 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.
 >=20
 > 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.
 >=20
 > The first thing is let's confirm that I'm understanding your question
 > correctly.  What happens is that:
 >=20
 > 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).
 >=20
 > and
 >=20
 > d) when jail is shut down, when you connect to the jail's IP, you
 > connected into the host.
 >=20
 > 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:
 >=20
 > 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
 >=20
 > Then, you basically have a setuid binary that can be reached from host
 > system.  As an attacker I would do:
 >=20
 > host$ /path/to/jail/bin/root_shell
 > #
 >=20
 > So the solution would be to change your configuration such that:
 >=20
 > 1) Do not give shell access to jail users unless they are also host
 > system administrator.
 >=20
 > 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.
 >=20
 > Cheers,
 > - --=20
 > Xin LI <delphij@delphij.net>    https://www.delphij.net/
 > FreeBSD - The Power to Serve!           Live free or die
 > -----BEGIN PGP SIGNATURE-----
 > Version: GnuPG v2.0.22 (FreeBSD)
 >=20
 > 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
 > =3Dky3s
 > -----END PGP SIGNATURE-----
 > _______________________________________________
 > 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=
 "
 
 --Apple-Mail-0F6E6005-A48F-492F-92E2-7CAB57D85559
 Content-Type: text/html;
 	charset=utf-8
 Content-Transfer-Encoding: quoted-printable
 
 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
 utf-8"></head><body dir=3D"auto"><div>I would also add &nbsp;. . . separate s=
 sh keys and passwords if the user needs access to both host and jailed syste=
 ms. This is just common practice and not a security flaw by any means but an=
  engineering oversight.</div><div><br></div><div>Popsicle sticks also have a=
  security flaw, they let you jab yourself in the throat if you fall while su=
 cking on them. Solution . . . sit down.<br><br><div><div style=3D"color: rgb=
 (163, 163, 163); font-family: Ubuntu-Regular; font-size: 16px; -webkit-tap-h=
 ighlight-color: rgba(26, 26, 26, 0.294118); -webkit-composition-fill-color: r=
 gba(175, 192, 227, 0.231373);">--&nbsp;</div><div style=3D"color: rgb(163, 1=
 63, 163); font-family: Ubuntu-Regular; font-size: 16px; -webkit-tap-highligh=
 t-color: rgba(26, 26, 26, 0.294118); -webkit-composition-fill-color: rgba(17=
 5, 192, 227, 0.231373);">&nbsp;Jason Hellenthal</div><div style=3D"color: rg=
 b(163, 163, 163); font-family: Ubuntu-Regular; font-size: 16px; -webkit-tap-=
 highlight-color: rgba(26, 26, 26, 0.294118); -webkit-composition-fill-color:=
  rgba(175, 192, 227, 0.231373);">&nbsp;Voice:&nbsp;<span style=3D"-webkit-ta=
 p-highlight-color: rgba(26, 26, 26, 0.301961); -webkit-composition-fill-colo=
 r: rgba(175, 192, 227, 0.235294);">95.30.17.6/616</span></div></div><div sty=
 le=3D"color: rgb(163, 163, 163); font-family: Ubuntu-Regular; font-size: 16p=
 x; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.294118); -webkit-composit=
 ion-fill-color: rgba(175, 192, 227, 0.231373);">&nbsp;JJH48-ARIN</div></div>=
 <div><br>On Mar 5, 2014, at 18:39, Xin Li &lt;<a href=3D"mailto:delphij@delp=
 hij.net">delphij@delphij.net</a>&gt; wrote:<br><br></div><blockquote type=3D=
 "cite"><div><span>-----BEGIN PGP SIGNED MESSAGE-----</span><br><span>Hash: S=
 HA512</span><br><span></span><br><span>On 03/05/14 15:07, Nicola Galante wro=
 te:</span><br><blockquote type=3D"cite"><span>I found a potential vulnerabil=
 ity with FreeBSD jails. I installed a</span><br></blockquote><blockquote typ=
 e=3D"cite"><span>server (hostserver) for my institute. This hostserver has a=
  certain</span><br></blockquote><blockquote type=3D"cite"><span>IP address, l=
 et's say 10.0.0.100, and I installed and configured</span><br></blockquote><=
 blockquote type=3D"cite"><span>three service jails (elog, mail, www), each w=
 ith a different IP</span><br></blockquote><blockquote type=3D"cite"><span>ad=
 dress (10.0.0.101, 10.0.0.102, 10.0.0.103)</span><br></blockquote><blockquot=
 e type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><spa=
 n>root@hostserver:/jails/j # jls JID &nbsp;IP Address &nbsp;&nbsp;&nbsp;&nbs=
 p;&nbsp;Hostname</span><br></blockquote><blockquote type=3D"cite"><span>Path=
  1 &nbsp;10.0.0.101 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elogjail &nbsp;&nbsp;&nbsp=
 ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
 sp;&nbsp;/jails/j/elog 2</span><br></blockquote><blockquote type=3D"cite"><s=
 pan>10.0.0.102 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mailjail &nbsp;&nbsp;&nbsp;&nbs=
 p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
 bsp;/jails/j/mail 3</span><br></blockquote><blockquote type=3D"cite"><span>1=
 0.0.0.103 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;wwwjail &nbsp;&nbsp;&nbsp;&nbsp;&nbs=
 p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
 bsp;/jails/j/www</span><br></blockquote><blockquote type=3D"cite"><span></sp=
 an><br></blockquote><blockquote type=3D"cite"><span>I have an account on bot=
 h the hostserver and the elogjail. Password</span><br></blockquote><blockquo=
 te type=3D"cite"><span>authentication on hostserver and ssh key authenticati=
 on in the</span><br></blockquote><blockquote type=3D"cite"><span>jail. The s=
 ervice sshd is running on both the hostserver and</span><br></blockquote><bl=
 ockquote type=3D"cite"><span>elogjail. If I ssh into the elogjail</span><br>=
 </blockquote><blockquote type=3D"cite"><span></span><br></blockquote><blockq=
 uote type=3D"cite"><span>[galante@caronte ~]$ ssh galante@elogjail Enter pas=
 sphrase for key</span><br></blockquote><blockquote type=3D"cite"><span>'/hom=
 e/galante/.ssh/id_dsa': Last login: Wed Mar &nbsp;5 21:37:23 2014</span><br>=
 </blockquote><blockquote type=3D"cite"><span>from caronte galante@elogjail:~=
  %</span><br></blockquote><blockquote type=3D"cite"><span></span><br></block=
 quote><blockquote type=3D"cite"><span>as expected. But if I turn off the ssh=
 d service in elogjail (and</span><br></blockquote><blockquote type=3D"cite">=
 <span>keep the elogjail up and running) and I try to connect to elogjail,</s=
 pan><br></blockquote><blockquote type=3D"cite"><span>I first get a complaint=
  that the fingerprint for the RSA key sent</span><br></blockquote><blockquot=
 e type=3D"cite"><span>by the remote host has changed. If I remove the corres=
 ponding line</span><br></blockquote><blockquote type=3D"cite"><span>in my lo=
 cal .ssh/known_hosts file and try to reconnect, this is</span><br></blockquo=
 te><blockquote type=3D"cite"><span>what happens:</span><br></blockquote><blo=
 ckquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite=
 "><span>[galante@caronte ~]$ ssh galante@elogjail Password for</span><br></b=
 lockquote><blockquote type=3D"cite"><span>galante@hostserver: Last login: We=
 d Mar &nbsp;5 21:12:20 2014 from</span><br></blockquote><blockquote type=3D"=
 cite"><span>caronte galante@hostserver:~ %</span><br></blockquote><blockquot=
 e type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><spa=
 n>I log into the host system! Of course this is possible because I</span><br=
 ></blockquote><blockquote type=3D"cite"><span>have an account on both the ho=
 st system and the jail. However, I</span><br></blockquote><blockquote type=3D=
 "cite"><span>believe that this can cause a serious potential security threat=
 . I</span><br></blockquote><blockquote type=3D"cite"><span>can envision seve=
 ral scenarios where somebody attempts to get into</span><br></blockquote><bl=
 ockquote type=3D"cite"><span>a jail and instead gets into the host system. I=
  checked also the</span><br></blockquote><blockquote type=3D"cite"><span>DNS=
  responsiveness. The problem persists even if I use IP addresses</span><br><=
 /blockquote><blockquote type=3D"cite"><span>instead of host names.</span><br=
 ></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>How-=
 To-Repeat:</span><br></blockquote></blockquote><blockquote type=3D"cite"><sp=
 an>Follow the steps described above.</span><br></blockquote><blockquote type=
 =3D"cite"><blockquote type=3D"cite"><span>Fix:</span><br></blockquote></bloc=
 kquote><blockquote type=3D"cite"><span>I don't know how to fix the problem o=
 ther than by disabling sshd in</span><br></blockquote><blockquote type=3D"ci=
 te"><span>the hostserver.</span><br></blockquote><span></span><br><span>I do=
 n't think this is a security issue and close this as invalid,</span><br><spa=
 n>however I'm bringing secteam@ and jamie@ in, just to make sure I</span><br=
 ><span>didn't understood the problem wrong.</span><br><span></span><br><span=
 >The first thing is let's confirm that I'm understanding your question</span=
 ><br><span>correctly. &nbsp;What happens is that:</span><br><span></span><br=
 ><span>a) you have account on *both* jail and host system.</span><br><span>b=
 ) you attempted to log in into jail's IP, which is also bound to host</span>=
 <br><span>system;</span><br><span>c) your configuration didn't explicitly sp=
 ecify SSH's listening</span><br><span>address on host, so it's a wildcard (L=
 isten 22 instead of Listen</span><br><span>hostip:22, where you can see in s=
 ockstat -4l as *:22 for sshd).</span><br><span></span><br><span>and</span><b=
 r><span></span><br><span>d) when jail is shut down, when you connect to the j=
 ail's IP, you</span><br><span>connected into the host.</span><br><span></spa=
 n><br><span>This is NOT a problem with jail. &nbsp;For starters, it's very b=
 ad idea to</span><br><span>give out host shell account, privileged or not, t=
 o jail users if they</span><br><span>are not trusted. &nbsp;Let's consider t=
 his scenario:</span><br><span></span><br><span>jail$ su -l</span><br><span>j=
 ail# cp /usr/bin/less /bin/root_shell</span><br><span>jail# chown root:wheel=
  /bin/root_shell</span><br><span>jail# chmod 6555 /bin/root_shell</span><br>=
 <span>jail# logout</span><br><span>jail$ logout</span><br><span></span><br><=
 span>Then, you basically have a setuid binary that can be reached from host<=
 /span><br><span>system. &nbsp;As an attacker I would do:</span><br><span></s=
 pan><br><span>host$ /path/to/jail/bin/root_shell</span><br><span>#</span><br=
 ><span></span><br><span>So the solution would be to change your configuratio=
 n such that:</span><br><span></span><br><span>1) Do not give shell access to=
  jail users unless they are also host</span><br><span>system administrator.<=
 /span><br><span></span><br><span>2) Do not make host's sshd to listen on all=
  addresses, instead, only</span><br><span>listen to the designated host IP a=
 ddress. &nbsp;This is not a security</span><br><span>measure but avoids conf=
 usion.</span><br><span></span><br><span>Cheers,</span><br><span>- -- </span>=
 <br><span>Xin LI &lt;<a href=3D"mailto:delphij@delphij.net">delphij@delphij.=
 net</a>&gt; &nbsp;&nbsp;&nbsp;<a href=3D"https://www.delphij.net/">https://w=
 ww.delphij.net/</a></span><br><span>FreeBSD - The Power to Serve! &nbsp;&nbs=
 p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Live free or die</span><br=
 ><span>-----BEGIN PGP SIGNATURE-----</span><br><span>Version: GnuPG v2.0.22 (=
 FreeBSD)</span><br><span></span><br><span>iQIcBAEBCgAGBQJTF7WXAAoJEJW2GBstM+=
 ns/dMP/2MdcY2FbXR7nl5cc5NL6Xyi</span><br><span>O87+Eee5QbJ4pRP/CdvTD4OivHi8B=
 ecS9egQDhtRuIvv6XtHWCD26KPuMUYgZd4U</span><br><span>8min9L/kfFLwlBIuH9CKGR0i=
 RzXDGY99NpRVpwSJBPxSeJrUZZzCMdoCwEQPvhkQ</span><br><span>S4TNv9+qiXmqDAwJbcT=
 FDUfhqc9FPuaLfdn/6+Cbi3MEAhJjaAuuvbZeUvhKLi/n</span><br><span>xavs3e9tqcy3i3=
 D6dJvSuOvDibBbrLpamch23VeyOMTZ78ahOKLa5dDAfkFJgx+g</span><br><span>JicfTcdcS=
 iPEutPenJo1bWUn5DbW1+aoNL+acBLty9Q0iknn8dcSG6PWDHnz3pmq</span><br><span>+hE8=
 lOq+7HGkVoqIGtDULlPy2eEeM6WwjUj4wcAQI7PfStkTc7eqJooj76mMmPg7</span><br><span=
 >CKF0yaqAG/57Qys4G6eVRxW8sAV33k8gaeTjjrRX6tFYZvZElSZ57shxZPinxzQe</span><br>=
 <span>XAAyq2E1gkxKnnvFZGEJSv4kmyE0u4jJAGW17N3x04R/VjPgtdBKZ4YeG3HoHdh3</span=
 ><br><span>vJ9LBUuZvx3zy0bVslJFKTNQq3tvCWhOkf4dITHKm2JBpaeo9VwGs50yUKYg/3NB<=
 /span><br><span>//NDUnQCF9rpoqU40w9JKEOiWO+nZLUzdXLerI8TccU15Mz0dpo+06oC6e72=
 DVtG</span><br><span>aUQS8DKHmWB9SwgXX02d</span><br><span>=3Dky3s</span><br>=
 <span>-----END PGP SIGNATURE-----</span><br><span>__________________________=
 _____________________</span><br><span><a href=3D"mailto:freebsd-security@fre=
 ebsd.org">freebsd-security@freebsd.org</a> mailing list</span><br><span><a h=
 ref=3D"http://lists.freebsd.org/mailman/listinfo/freebsd-security">http://li=
 sts.freebsd.org/mailman/listinfo/freebsd-security</a></span><br><span>To uns=
 ubscribe, send any mail to "<a href=3D"mailto:freebsd-security-unsubscribe@f=
 reebsd.org">freebsd-security-unsubscribe@freebsd.org</a>"</span><br></div></=
 blockquote></body></html>=
 
 --Apple-Mail-0F6E6005-A48F-492F-92E2-7CAB57D85559--
 
 --Apple-Mail-B57BD488-AE1F-4C09-AEEE-4BF1170F2439
 Content-Type: application/pkcs7-signature;
 	name=smime.p7s
 Content-Disposition: attachment;
 	filename=smime.p7s
 Content-Transfer-Encoding: base64
 
 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw
 ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
 ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
 MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA
 ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ
 KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+
 YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB
 hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5
 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63
 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA
 AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
 BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg
 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud
 IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0
 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp
 Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y
 ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD
 b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj
 b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug
 KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB
 gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll
 bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz
 czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ
 KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf
 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO
 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ
 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC
 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC
 AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
 MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT
 dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy
 MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
 U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
 c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
 DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E
 RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1
 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur
 yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM
 TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV
 HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4
 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG
 AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93
 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0
 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh
 LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3
 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns
 LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5
 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS
 qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy
 +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj
 Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586
 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3
 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q
 ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx
 kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV
 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw
 DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp
 BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0
 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz
 NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
 ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj
 YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4
 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ
 Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N
 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo
 uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ
 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs
 DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B
 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/
 kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov
 gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw
 ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD
 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js
 LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud
 IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z
 dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u
 b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg
 KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv
 biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv
 cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku
 cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg
 Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs
 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR
 HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE
 w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T
 mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe
 SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98
 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous
 NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE
 GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig
 yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw
 gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg
 RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy
 aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3
 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMwNjA2NTUxM1owIwYJKoZIhvcN
 AQkEMRYEFL8SpszpkhyGJCklp1Blu9/vWW5bMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV
 BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD
 ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50
 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE
 BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl
 cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl
 cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEACQl+gza9aR72olXVkfuD
 dxp9EBsAoOVkzlzFtwpFQgPZIkhLOKukHFW/VLKH37mAjtXcMRkVg55M/g9KT+oQgKW+BW+VOQtX
 wx+rX10cwk3q2pZBS4GJ2x401p9HapyNq5niwTDckaFK+cNv5hylXXrIYe97lsSQ7qZRiG1SIndq
 kLsCEIQTJbqw9tDbTosUyjGudNZQ/yWZGXQbvrUPjg0ftt5cPMrpkgTEgq10yl3c0esADC7VhL9O
 1vNQOULOGrMYuDjblNWfm5GR1XomwQcz/NSEnBeBGk5y43R51VFZuoHMbVOqE+OOq7Vz0+ZM7GW7
 Jdv7lDWkdH3K8WetDQAAAAAAAA==
 
 --Apple-Mail-B57BD488-AE1F-4C09-AEEE-4BF1170F2439--

From: Randy Schultz <schulra@earlham.edu>
To: Nicola Galante <galante@veritas.sao.arizona.edu>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail
Date: Thu, 6 Mar 2014 08:09:01 -0500 (EST)

 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
 

From: Shawn Webb <lattera@gmail.com>
To: Jason Hellenthal <jhellenthal@dataix.net>
Cc: "d@delphij.net" <d@delphij.net>, 
	"freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, 
	"freebsd-gnats-submit@FreeBSD.org" <freebsd-gnats-submit@freebsd.org>, 
	"secteam@FreeBSD.org" <secteam@freebsd.org>, "jamie@FreeBSD.org" <jamie@freebsd.org>, 
	Nicola Galante <galante@veritas.sao.arizona.edu>
Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail
Date: Thu, 6 Mar 2014 09:10:33 -0500

 --089e013a062c5778a604f3f0b366
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Thu, Mar 6, 2014 at 1:55 AM, Jason Hellenthal <jhellenthal@dataix.net>wrote:
 
 > I would also add  . . . separate ssh keys and passwords if the user needs
 > access to both host and jailed systems. This is just common practice and
 > not a security flaw by any means but an engineering oversight.
 >
 > Popsicle sticks also have a security flaw, they let you jab yourself in
 > the throat if you fall while sucking on them. Solution . . . sit down.
 
 
 One can also use vnet (VIMAGE kernel option) in conjunction with jails to
 give each jail its own full TCP/IP stack, rather than sharing the TCP/IP
 stack with the host.
 
 --089e013a062c5778a604f3f0b366
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
 hu, Mar 6, 2014 at 1:55 AM, Jason Hellenthal <span dir=3D"ltr">&lt;<a href=
 =3D"mailto:jhellenthal@dataix.net" target=3D"_blank">jhellenthal@dataix.net=
 </a>&gt;</span> wrote:<br>
 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
 x #ccc solid;padding-left:1ex">I would also add =A0. . . separate ssh keys =
 and passwords if the user needs access to both host and jailed systems. Thi=
 s is just common practice and not a security flaw by any means but an engin=
 eering oversight.<br>
 
 <br>
 Popsicle sticks also have a security flaw, they let you jab yourself in the=
  throat if you fall while sucking on them. Solution . . . sit down.</blockq=
 uote><div><br></div><div>One can also use vnet (VIMAGE kernel option) in co=
 njunction with jails to give each jail its own full TCP/IP stack, rather th=
 an sharing the TCP/IP stack with the host.=A0</div>
 </div><br></div></div>
 
 --089e013a062c5778a604f3f0b366--

From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: d@delphij.net
Cc: Nicola Galante <galante@veritas.sao.arizona.edu>,  freebsd-gnats-submit@FreeBSD.org,  "freebsd-security\@freebsd.org" <freebsd-security@freebsd.org>,  jamie@FreeBSD.org,  "secteam\@FreeBSD.org" <secteam@FreeBSD.org>
Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail
Date: Thu, 20 Mar 2014 13:36:40 +0100

 Xin Li <delphij@delphij.net> writes:
 > 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).
 > d) when jail is shut down, when you connect to the jail's IP, you
 > connected into the host.
 
 I would like to point out that if you follow the documented procedure
 for configuring and managing jails, the jail's IP goes away when the
 jail shuts down.  This has been the case since at least 8.x using the
 old-style rc.conf variables (jail_foo_interface, jail_foo_ip), and it is
 still the case in 10.0 using the new-style jail.conf.
 
 DES
 --=20
 Dag-Erling Sm=C3=B8rgrav - des@des.no
>Unformatted:
