[Date Prev][Date Next] [Chronological] [Thread] [Top]

Security, environment, setuid: general OpenLDAP vulnerability

Hello people.

Do development team realize that the current option processing
implementation is vulnerable in some particular situations (i.e.
setuid programs)? I mean environment and .ldaprc files. Mail transfer
agents are good candidates for both running with setuid and using

Processing of system-wide /etc/openldap/ldap.conf (or whatever) by
default is okay. In this case robust implementaion should check that
it is not world-writable. But when someone runs program as setuid in a
malicious environment, this can compromise system by altering, for
instance, hosts (if they are not set explicitly). Another thing is
that TLS options can be altered (and give us DoS or something like
this). Environment is *generally* *insecure*.

I guess setenv("LDAPNOINIT", "yes", 1) is not enough.
I don't know the software which is aware of such things. Every setuid
program must be recompiled to make such setenv() call. But this is
more openldap-software question...

Well-known MySQL uses another precedence of options, i.e. those that
set in any option files or explicitly (system-wide or .my.cnf)
*override* environment.

What could be done by OpenLDAP library?

I think that disabling some dangerous behaviour with mechs such as
environment is a bit ugly in general. But I don't have a clear view on
how it can be implemented in a more efficient manner (by calling
ldap_set_option() with something like LDAP_OPT_NOINIT).
This has the same chicken-and-egg problem as for setting debugging

Another approach is to implement ldap_set_option() argument
LDAP_OPT_INITRC that contains a file which overrides everythig. Again,
implementation should check that it is not world-writable and give
approrpiate warnings.

Сurrently there is no ability to set any custom configuration file in
a safe manner. TLS private key can only be given in a ldaprc file,
which is in $HOME, or again can be set by environment. Ugly.

But disabling such things completely is not a good way since it breaks

Can You give me some comments on this? I'm interested in Exim+OpenLDAP
solution. That's the setuid MTA which is very popular and I must patch
either Exim or OpenLDAP library to be sure that everything is okay.
BTW Exim is now aware of ldapi:// URL schemes, but ldaps:// is still
far from perfect...

If something reasonable could be done with OpenLDAP library, I want
the community to get benefits on it, not just myself.

Thank You.
Best regards,
 Peter                          mailto:spam4octan@highway.ru