* Gabor Gombas ([EMAIL PROTECTED]) wrote: > On Thu, Sep 14, 2006 at 03:02:34PM -0400, Stephen Frost wrote: > > > Certainly possible.. If that's the case then there's nothing > > libnss-ldap could do about it tho and this would be an issue with > > libldap. What happens if the ldap.conf doesn't exist? Is that > > something you could test? > > The same: the TLS negotiation fails. Looking at the code, I think I > found the bug: in ldap-nss.c, the do_ssl_options() is invoked only if > either "ssl on" or "ssl start_tls" is specified in the config file. But > I have neither, I simply have "uri ldaps://..." in libnss-ldap.conf.
Erm, is there some reason you don't have 'ssl on' in your config?
> Playing with this I think this case is also a security hole: since
> libldap always reads an "ldaprc" file in the current directory, any user
> can override the CA certificate file option thus potentially making
> set-uid programs accept data from an untrusted LDAP server.
I'm curious about this, are you sure a libldap would read an "ldaprc"
file when run from a setuid program? Or that it'd read the
current-directory ldaprc in that situation? Can you provide an strace
showing this happening? This would almost certainly be an issue in
libldap, of course, if it's acting as you describe.
Also, the user would have to have access to more than the ldaprc file,
no? Since the user couldn't control what server is being connected to
without more control on the system, or control over the DNS, etc.
Thanks,
Stephen
signature.asc
Description: Digital signature
