Date: Thu, 6 Mar 2014 01:55:11 -0500 From: Jason Hellenthal <jhellenthal@dataix.net> To: "d@delphij.net" <d@delphij.net> Cc: "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 Message-ID: <0E7A07FB-FE42-41BE-9FE2-36558C421411@dataix.net> In-Reply-To: <5317B597.5050900@delphij.net> References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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@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@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----- > _______________________________________________ > 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" [-- Attachment #2 --] 0 *H 01 0 + 0 *H 90000 *H 01 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 130518085048Z 140519220947Z0H1 0 U jhellenthal@dataix.net1%0# *H jhellenthal@dataix.net0"0 *H 0 '`TmfkܨJ5u +c'Upb`zv)&ȸXZ*VN6JvLoVoh}g pQDŽKf/tZA˳( "4Ԅ˻'d2h| IBl' ^v^;'e8S99ۿVm|k8_UQtC"5l!kjZ]އQGn \Bh!F TsD%pV^Eӑd¨x"9 г" f 00 U 0 0 U 0 U %0++0 U ڔfmVʢ$䟓0 U #0Sr풜\|~5NԸQ0!U 0jhellenthal@dataix.net0LU C0?0; +70*0.+"http://www.startssl.com/policy.pdf0+00' StartCom Certification Authority0This certificate was issued according to the Class 1 Validation requirements of the StartCom CA policy, reliance only for the intended purpose in compliance of the relying party obligations.06U /0-0+)'%http://crl.startssl.com/crtu1-crl.crl0+009+0-http://ocsp.startssl.com/sub/class1/client/ca0B+06http://aia.startssl.com/certs/sub.class1.client.ca.crt0#U 0http://www.startssl.com/0 *H {0Ӹ,52W{Ey8b [ {7 _+P"n["-,@ŽpJ-W$ݍjWA-6z( RdIZ. KzXє[ K6}{s+v.Qh0PͅK hTw 0I73lz*K v4Kkگ63;p1:ױ@)]ok>:W%XwC1þL/o8~#oP040 0 *H 0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0 071024210155Z 171024210155Z01 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0"0 *H 0 -).2AUGo#G B|NDRpM-B=o -we5JQpa>O.#._<V [~**pz~3WG .ᘟMlr[<Ce6fqO"uxfWN#uicgkv$Lb%y`_{`xK'GN 00U 00U 0 U Sr풜\|~5NԸQ0 U #0N @[i04hCA0f+Z0X0'+0http://ocsp.startssl.com/ca0-+0!http://www.startssl.com/sfsca.crt0[U T0R0'%#!http://www.startssl.com/sfsca.crl0'%#!http://crl.startssl.com/sfsca.crl0U y0w0u +70f0.+"http://www.startssl.com/policy.pdf04+(http://www.startssl.com/intermediate.pdf0 *H }x,\c^ #wMq}>UK/^yX֏y frMIŲB61ymQҨݬZ0& ;@#13qۑ& ̢o 6r_;GO>*I( 74XS1r3)!LJy6Kotˆ# _wSr ;B ADp(fs 䰷6%.W0J3:bC<8t X1<Cn=t==wST~\wkBf|15zUP)(IjVB!OfI=bb\4-*em/нSJm7N[]'@ڽ D9Kr>R7/|o^I@ټ'Pa $ z9a'L)( I}vcH]۸D*W} m>Q|C.(,lQ000 *H 0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0 060917194636Z 360917194636Z0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0"0 *H 0 lF|x{3rb6 "$^wC d̎68#nm<r =3+/AYg} tyL7z9RYFC҅qub4, 4ǖR=3M ;JK&/ r5w<]&6v\t%x- 0-ryF*I cSb:̵fkt+v>mDsb ;ľSV%lQ ʿvmۿ=f VH:KߧXP8u[C lMp[)eݪ]̯1 ҍ{n'f HnB?!>{ pclT\%zɢɋ,~^MXn 2n6IHiMi y"H{ipz7 vOW`g:ԋr"Ɵƶ\R<*s `z/ۣn&0݉W=+ŷv+*r3] KtRK R0N0 U 00 U 0 U N @[i04hCA0dU ]0[0,*(&http://cert.startcom.org/sfsca-crl.crl0+)'%http://crl.startcom.org/sfsca-crl.crl0]U T0P0L +70;0/+#http://cert.startcom.org/policy.pdf05+)http://cert.startcom.org/intermediate.pdf0+00' Start Commercial (StartCom) Ltd.0Limited Liability, read the section *Legal Limitations* of the StartCom Certification Authority Policy available at http://cert.startcom.org/policy.pdf0 `HB 08 `HB +)StartCom Free SSL Certification Authority0 *H lf 4Ѕ^} N8 ^ߦ%K2;=D [I)f% <6+Kh9f=&9 Q{~ZWpi^X ߌE8 ^Wbz )n(DÐ8<CMdE(\s{諱.\dns1:}Q;Mf{<Ӛ ePu/CiyCFrd6% 8w~kjDKx, KD4R' ]xS2݀fuٵh(a.8 gd./pǖ|eCTݥ9`4ɖp, H{ ~k";*RKU"4N&",uJ} d6/# ;sIjWxřCcMw-eriG V$ yX. ~m >J9+u U77Cb VKel$$4"}?eQ 0j r^1o0k001 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 + 0 *H 1 *H 0 *H 1 140306065513Z0# *H 1 $)%PeYn[0 +71001 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 *H 101 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 *H ~6i UՑw} d\ŷ EB"HK8 UT߹1LJOo9 W _] MږAK 4֟Gj0ܑJo ]za{ĐQmR"wj%N1tP%t \<Ăt] .ՄNP9B8۔՟z&3ԄNrtyQYmS㎫sLe%5t}g
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E7A07FB-FE42-41BE-9FE2-36558C421411>