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/ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
