openssh unix dev - Jul 2018 - naive sftp user point of view was: SFTP chroot: Writable root

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.
> 
> As the 2009 CVE activities mention, that creating hardlinks
> from outside gives trivial chroot, I showed that any cooperating
> access from the outside - no matter if it is the same user or
> another one - leads to root privilege escalation, even without
> hardlinks, just using the default behaviour of any shared linked
> SUID binary.
> 
> hd
> 
> [0] https:///www.halfdog.net/Security/2018/OpensshSftpChrootCodeExecution/
> 

Hello halfdog,

I was not aware that a sftp-only access does execute code/scripts from these
directories.

I look at this from the point of view of a naive sftp user.

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.


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.

Don't get me wrong, I am a happy OpenSSH user since several years. I use it
daily and it is rock solid. Thank
you very much for this great tool!

Regards,
   Thomas G?ttler





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

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/

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