naive sftp user point of view was: SFTP chroot: Writable root

[halfdog]

Thomas Güttler writes:
> Some months have passed. Is the "visible dark stop" around?
> ...

Nothing new yet. The "writable root" weak configuration post
authentication remote code execution case is far too unlikely
to exist on real world servers, so that I stopped exploring this
direction or attempting to get a CVE. Maybe sftp maintainers
want to push a patch or update documentation if they see any
priority in improving the current situation.

For the container escape: it seems that they did everything right,
so I did not manage to escape in userspace. Maybe I will give
it another try later on.

hd

> Am 09.01.2018 um 21:22 schrieb halfdog:
> > Hello Thomas,
> > 
> > Thomas Güttler writes:
> >> 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.
> >>> [...]
> >>
> >> Hello halfdog,
> >>
> >> I was not aware that a sftp-only access does execute code/scripts
> >> from these directories.
> > 
> > Me neither. But that's why it is always worth checking ...
> > 
> >> I look at this from the point of view of a naive sftp user.
> > 
> > A good point of view - because it relates to safe defaults
> > someone might expect to find, when using software.
> > 
> >> 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.
> > 
> > It is definitely a quite visible dark stop - and an excellent
> > motivate to dive deeper. I hope to have more time to look into
> > it after tommorrow's publication. As always: ars longa, vita brevis.
> > 
> >> 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.
> > 
> > That is correct. Therefore OpenSSH security might evaluate if
> > that flaw is a violation of specification - then it is a security
> > bug and should be handled as such. Alternatively, this is admin
> > error. If it could be "common admin error", better documentation
> > or warnings should be a good countermeasure.
> > 
> > Currently documentation is cryptic:
> > 
> >    "For safety, it is very important that the directory hierarchy be
> >    prevented from modification by other processes on the system
> >    (especially those outside the jail).  Misconfiguration can lead
> >    to unsafe environments which sshd(8) cannot detect."
> > 
> > Modification from outside, as shown in [0], is trivial local-root
> > privilege escalation. But what "the directory hierarchy" is could
> > be more clear. Could refer to file hierarchy standard (FHS) also,
> > then allowing user directories like /dev or /usr would be admin
> > error.
> > 
> > hd
> > 
> > [0] https://www.halfdog.net/Security/2018/OpensshSftpChrootCodeExecution/