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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux