openssh unix dev - Jan 2018 - SFTP chroot: Writable root

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/

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.