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