ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names

[Alexander Wuerstlein]

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.