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

Thomas Güttler guettliml at
Mon Jul 16 22:37:25 AEST 2018

Some months have passed. Is the "visible dark stop" around?

    Thomas Güttler

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]
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at

Thomas Guettler
I am looking for feedback:

More information about the openssh-unix-dev mailing list