On Fri, Jan 05, 2018 at 09:42:18PM +1030, David Newall wrote:> On 05/01/18 20:06, Jakub Jelen wrote: > > if the confined user has write access to the chroot directory, > > there are ways how to get out, gain privileges and or do other > > nasty things. > > I'm not inexperienced with UNIX and unix-like operating systems (30+ years), > and I can't think what these ways are.? Although clearly off-topic, I wonder > if you could expound on this?The attack involves being able to create hard links inside the chroot referring to setuid programs outside the chroot. If you can do that then you can e.g. make a hard link to the external /bin/su, construct your own /etc/passwd and so on, and thereby gain root inside the chroot. Chroots are easily escapable by root (e.g. https://filippo.io/escaping-a-chroot-jail-slash-1/). The particular case Jakub is referring to is: https://bugzilla.redhat.com/show_bug.cgi?id=522141 https://lists.mindrot.org/pipermail/openssh-unix-dev/2008-November/026981.html has some recommendations for making the default directory that users start in be writable in a less dangerous way. -- Colin Watson [cjwatson at debian.org]
Hello list, I created a page to demonstrate, what would happen when chroot root directory is writeable. In fact, code execution is possible already, when only /etc and /bin are writable. I also tried to escape the chroot jail, but that did not work for non-root users. As the 2009 CVE activities mention, that creating hardlinks from outside gives trivial chroot, I showed that any cooperating access from the outside - no matter if it is the same user or another one - leads to root privilege escalation, even without hardlinks, just using the default behaviour of any shared linked SUID binary. hd [0] https:///www.halfdog.net/Security/2018/OpensshSftpChrootCodeExecution/
Thomas Güttler
2018-Jan-08 08:46 UTC
naive sftp user point of view was: SFTP chroot: Writable root
Am 07.01.2018 um 19:41 schrieb halfdog:> Hello list, > > I created a page to demonstrate, what would happen when chroot > root directory is writeable. In fact, code execution is possible > already, when only /etc and /bin are writable. I also tried to > escape the chroot jail, but that did not work for non-root users. > > As the 2009 CVE activities mention, that creating hardlinks > from outside gives trivial chroot, I showed that any cooperating > access from the outside - no matter if it is the same user or > another one - leads to root privilege escalation, even without > hardlinks, just using the default behaviour of any shared linked > SUID binary. > > hd > > [0] https:///www.halfdog.net/Security/2018/OpensshSftpChrootCodeExecution/ >Hello halfdog, I was not aware that a sftp-only access does execute code/scripts from these directories. I look at this from the point of view of a naive sftp user. If a naive sftp user get access to a machine, then he thinks the directory belongs to him and he can write and delete whatever he wants. I don't know much about the internals of sftp, but I think the point of view of a naive sftp user is valid. I guess there is no distinction between root-directory for data and root-directory for config/code up to now. This missing distinction leads to execution of data, which is (of course) a major security issue. If you compare it to webDAV, NFS or SMB. There would be something really wrong if the WebDAV/NFS/SMB server would suddenly execute uploaded data. Don't get me wrong, I am a happy OpenSSH user since several years. I use it daily and it is rock solid. Thank you very much for this great tool! Regards, Thomas G?ttler -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
On Sun, 2018-01-07 at 18:41 +0000, halfdog wrote:> Hello list, > > I created a page to demonstrate, what would happen when chroot > root directory is writeable. In fact, code execution is possible > already, when only /etc and /bin are writable. I also tried to > escape the chroot jail, but that did not work for non-root users. > > As the 2009 CVE activities mention, that creating hardlinks > from outside gives trivial chroot, I showed that any cooperating > access from the outside - no matter if it is the same user or > another one - leads to root privilege escalation, even without > hardlinks, just using the default behaviour of any shared linked > SUID binary. > > hd > > [0] > https:///www.halfdog.net/Security/2018/OpensshSftpChrootCodeExecution > /Thank you for the article describing this issue in understandable manner. What struck my attention is the reading of the /etc/ssh/sshrc from chroot. Is it even correct that OpenSSH is searching for the /etc/ssh/sshrc file AFTER the chroot? No, I am not advocating the writable chroots, but is sounds to me wrong, or at least nothing I would expect. Even though it is not exploitable out of the box, it might be if one chooses "wrong" names for users directories (well ... etc/ might not be too uncommon). Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc.