SFTP chroot: Writable root

[halfdog]

David Newall writes:
> On 06/01/18 01:05, Jakub Jelen wrote:
>> the description of the CVE 2009-2904 [1] talks about attack
>> vector with hardlinks and suid programs. Though I didn't
>> investigate it further.
>>
>> [1]https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904
>
> Yes, of course, that requires users to also have access outside
> of the chroot, as well as the ability to execute an arbitrary
> command within it. It doesn't appear to be a problem where
> ForceProgram sftp-server is effective.
>
> I note that Ubuntu 16 (I assume some others, too) refuses to
> hard link a file to which the user cannot write. I don't remember
> if that is traditional behaviour; I think not; it's probably
> SELinux.
>
> Even without SELinux's protection, I'm still not seeing a risk
> when the user has no access outside of the chroot (by which
> I include having no ally with said access). Is there more to
> the risk?
>
> Bringing this back to on topic, to the question that was originally
> asked: the above reference shows that there is more to consider
> than just what's in a chroot, and so providing a writable root
> is not to be encouraged, however, if it is essential to allow
> an SFTP account to have write access to its root, (I doubt
> that there is an essential need), putting the chroot on a separate
> filesystem, mounted with noexec, should also be considered.

If everything is done correct, this might suffice, but I would
not want to be the one who has assisted a remote compromise.

Writable root is ultra-risky in any way from multiple perspectives.
Attacks can abuse the assumption built into various applications
and libraries, that the / directory is trusted. So when they
load data from /usr or /lib, this data is also trusted. As soon
as / is writable, this assumption does not hold true any more.
Depending on the scenario, there can be various ways to gain
control.

With a cooperating local user having write access to the directory
in the shell, this is an immediate and inevitable issue. Hardlinks
or command execution in chroot is oldstyle and can be prohibited,
as you stated, so CVE-2009... might really not apply regarding SUID.

But there are so many other options, that I would just not risk
it. To evade, I would do the following:

* Create a custom /lib directory and try to make process read it
by subprocess invocation or triggering other delayed loading features,
e.g. loading of /lib/x86_64-linux-gnu/libgcc_s.so.1 on errors
(libgcc_s.so.1 is the thing that dumps memory map information
for debugging when malloc/free fails).

* If the simplest /lib way does not work, upload locale data for
all linked libraries to /usr/share/locale/. gettext() and locale
will only search for them when needed, so any response translation
from a the program or library, that was not loaded before will
load them. And as they are passed to printf as format, you have
full stack control. Maybe you have force-command, but have you
also disabled all SSH environment passing to avoid fucking with
LANG, LC_ALL, TZ, ...?

* Check if program/libs are searching for /proc. Even when required
for function (programs might continue silently when e.g. /proc/mountinfo)
is not found, but internally the library will still try. I remember
at least 3 privilege escalations, that were related to rogue /proc
data.

So, this is just the first 3 options, I would go for. Just tell
me the name of your server, and I evaluate if it would be worth
thinking longer about the problem.

hd