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. -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Mar 5, 2014, at 18:39, Xin Li <[email protected]> wrote: > > -----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 <[email protected]> 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----- > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "[email protected]"
smime.p7s
Description: S/MIME cryptographic signature
