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

[Thomas Güttler]

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

Regards,
    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] https://www.halfdog.net/Security/2018/OpensshSftpChrootCodeExecution/
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines