Alexander Wuerstlein
2017-May-18 13:38 UTC
ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names
On 2017-05-18T13:13, mh at ow2.org <mh at ow2.org> wrote:> Le 18/05/2017 ? 12:17, mh at ow2.org a ?crit : > > However, I get uid/gid numbers instead of names within sftp session (ls > > -l) ? I don't know if it's new but I would definitively prefer names... > > It seems the reason is : > > open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) > > okay, etc folder in the chroot wasn't world readable. If I put an entry > in the passwd file, the sftp session start resolving names. > > Notice the sftp process is owned by the connecting user, and if etc/ > folder is world readable, it means I expose those file to sftp user. I > don't like it but unsure if there is a better solution... > > Or I could simply only resolve entries from the ldap and get rid of > passwd file (see below). > > I also had this error: > socket(PF_LOCAL, SOCK_STREAM, 0) = 4 > fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) > fcntl(4, F_SETFD, FD_CLOEXEC|0x2) = 0 > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) > -1 ENOENT (No such file or directory) > > Of course /var/run/nslcd/socket doesn't exist in the chroot. > > To solve this I did : > mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/Yes, and additionally you want to get rid of 'compat' nsswitch entries, because those also consult the passwd/group/... files. Another option, if you don't want to have a socket reaching out of the chroot (including the corresponding possible chroot escape possibility) is to just "copy everything from ldap into a local file". Which would be exactly what https://github.com/google/nsscache does. YMMV. Ciao, Alexander Wuerstlein.
mh at ow2.org
2017-May-19 06:52 UTC
ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names
Le 18/05/2017 ? 15:38, Alexander Wuerstlein a ?crit :> On 2017-05-18T13:13, mh at ow2.org <mh at ow2.org> wrote: >> Le 18/05/2017 ? 12:17, mh at ow2.org a ?crit : >>> However, I get uid/gid numbers instead of names within sftp session (ls >>> -l) ? I don't know if it's new but I would definitively prefer names... >> >> It seems the reason is : >> >> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) >> >> okay, etc folder in the chroot wasn't world readable. If I put an entry >> in the passwd file, the sftp session start resolving names. >> >> Notice the sftp process is owned by the connecting user, and if etc/ >> folder is world readable, it means I expose those file to sftp user. I >> don't like it but unsure if there is a better solution... >> >> Or I could simply only resolve entries from the ldap and get rid of >> passwd file (see below). >> >> I also had this error: >> socket(PF_LOCAL, SOCK_STREAM, 0) = 4 >> fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) >> fcntl(4, F_SETFD, FD_CLOEXEC|0x2) = 0 >> connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) >> -1 ENOENT (No such file or directory) >> >> Of course /var/run/nslcd/socket doesn't exist in the chroot. >> >> To solve this I did : >> mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/ > > Yes, and additionally you want to get rid of 'compat' nsswitch entries, > because those also consult the passwd/group/... files. > > Another option, if you don't want to have a socket reaching out of the > chroot (including the corresponding possible chroot escape possibility) > is to just "copy everything from ldap into a local file". Which would be > exactly what https://github.com/google/nsscache does. YMMV. >Hi Alex, Thanks, Well, yes, but isn't it comes down exposing all the users entries to the sftp users? (as I've mentioned above). In my case it's not that critical but still i'm not comfortable with it in a chroot'd ftp context/usage.
Alexander Wuerstlein
2017-May-19 08:56 UTC
ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names
On 2017-05-19T08:52, mh at ow2.org <mh at ow2.org> wrote:> Le 18/05/2017 ? 15:38, Alexander Wuerstlein a ?crit : > > On 2017-05-18T13:13, mh at ow2.org <mh at ow2.org> wrote: > >> Le 18/05/2017 ? 12:17, mh at ow2.org a ?crit : > >>> However, I get uid/gid numbers instead of names within sftp session (ls > >>> -l) ? I don't know if it's new but I would definitively prefer names... > >> > >> It seems the reason is : > >> > >> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) > >> > >> okay, etc folder in the chroot wasn't world readable. If I put an entry > >> in the passwd file, the sftp session start resolving names. > >> > >> Notice the sftp process is owned by the connecting user, and if etc/ > >> folder is world readable, it means I expose those file to sftp user. I > >> don't like it but unsure if there is a better solution... > >> > >> Or I could simply only resolve entries from the ldap and get rid of > >> passwd file (see below). > >> > >> I also had this error: > >> socket(PF_LOCAL, SOCK_STREAM, 0) = 4 > >> fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) > >> fcntl(4, F_SETFD, FD_CLOEXEC|0x2) = 0 > >> connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nslcd/socket"}, 23) > >> -1 ENOENT (No such file or directory) > >> > >> Of course /var/run/nslcd/socket doesn't exist in the chroot. > >> > >> To solve this I did : > >> mount -o bind /var/run/nslcd/ <chrootfolder>/var/run/nslcd/ > > > > Yes, and additionally you want to get rid of 'compat' nsswitch entries, > > because those also consult the passwd/group/... files. > > > > Another option, if you don't want to have a socket reaching out of the > > chroot (including the corresponding possible chroot escape possibility) > > is to just "copy everything from ldap into a local file". Which would be > > exactly what https://github.com/google/nsscache does. YMMV. > > > > Hi Alex, > Thanks, > Well, yes, but isn't it comes down exposing all the users entries to the > sftp users? (as I've mentioned above). In my case it's not that critical > but still i'm not comfortable with it in a chroot'd ftp context/usage.Well, if you want UIDs resolved to names, you always have to expose the UID-name-mapping to the chroot somehow[0]. Considering this exposition of passwd, there is no big difference between doing it via LDAP or a passwd file imho. There are differences however. A file is a little easier to expose via sftp, since downloading files is what sftp does in normal operations, and a stray hardlink or some strange misconfiguration could expose it. Whereas with the nslcd socket, you would perhaps need a more complex vulnerability to be able to execute getent, talk to the socket, etc. However, such a problem which allows accessing the nslcd socket will enable an attacker to talk to the nslcd outside the chroot, ask it for a lot more mappings than just passwd (possibly stuff like 'shadow' containing password hashes...), it also might allow talking to your LDAP server directly over an authenticated connection, use LDAP exploits or expose a lot more data that isn't properly secured by LDAP ACLs. And maybe also escape the chroot via an nslcd vulnerability. So it comes down to your preferences and estimates as to how likely you think those possiblities might lead to a security problem, what the consequences would be and how easy it is to contain those problems. Ciao, Alexander Wuerstlein. [0] The only "advantage" LDAP has in that regard is that the server can do rate-limiting. But thats just smoke and mirrors, the attacker will get the data eventually. Also, rate-limiting properly is very hard, especially in this case where you would just want it for that one service, not the whole host or all of your network. Also, rate-limiting might also affect legitimate users who then will complain. I therefore consider it a very bad idea in general.