-----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 at 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 at caronte ~]$ ssh galante at elogjail Enter passphrase for key > '/home/galante/.ssh/id_dsa': Last login: Wed Mar 5 21:37:23 2014 > from caronte galante at 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 at caronte ~]$ ssh galante at elogjail Password for > galante at hostserver: Last login: Wed Mar 5 21:12:20 2014 from > caronte galante at 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 at 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-----
On 3/5/2014 4:39 PM, Xin Li wrote: > 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 That's an important point: jails are good for their *own* security, but they make the base system insecure for allowing untrusted users. I can see user accounts for the admin's own use (likely the condition that was originally reported), but that's the only account I would consider allowing. - Jamie
On Wed, Mar 5, 2014 at 5:39 PM, Xin Li <delphij at 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.
On Wed, Mar 5, 2014 at 11:39 PM, Xin Li <delphij at delphij.net> wrote:> 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 > # >As a defender I would hope that someone has already done: host# chmod 700 /path/to You're right though, jail users have no business on the host. Cheers Tom
Jason Hellenthal
2014-Mar-06 06:55 UTC
misc/187307: Security vulnerability with FreeBSD Jail
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 <delphij at delphij.net> 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 at 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 at caronte ~]$ ssh galante at elogjail Enter passphrase for key >> '/home/galante/.ssh/id_dsa': Last login: Wed Mar 5 21:37:23 2014 >> from caronte galante at 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 at caronte ~]$ ssh galante at elogjail Password for >> galante at hostserver: Last login: Wed Mar 5 21:12:20 2014 from >> caronte galante at 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 at 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----- > _______________________________________________ > freebsd-security at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140306/3f2cf9bc/attachment.bin>
Dag-Erling Smørgrav
2014-Mar-20 12:36 UTC
misc/187307: Security vulnerability with FreeBSD Jail
Xin Li <delphij at 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 -- Dag-Erling Sm?rgrav - des at des.no