Main Inclusion Report for libnss-ldap
Availability: http://archive.ubuntu.com/ubuntu/pool/universe/libn/libnss-ldap, available for all supported architectures
- Part of edubuntu-network-auth-server spec, needed for ldap network authentication
Some CVE entries in the past.
Similar entries in Secunia history.
- libnss-ldap is a module loaded by libpam.so, and is not directly executable. However, binaries that link to libpam.so are generally running as root or suid/sgid.
- libnss-ldap opens a random source port to a destination port that is either listed specifically in the configuration file, or determine from the URI of the destination.
- Source code review:
- All in Main
- libpam-ldap - currently in universe
- nscd - Name Service Cache Daemon - currently in universe
I have reviewed libnss-ldap 255-1. It consists of a total of about 17kloc of C code of which the proportion we use will depend very much on the configuration. It implements an NSS plugin in terms of libldap. The library is rather extensive (flabby) and doesn't give me a hugely good feeling; it does a lot of direct manipulation of memory management routines and LDAP data. The upstream is active but as an example of the problems with the maintenance of this package, upstream have not yet included a fix for a (probably hard to exploit) buffer overrun bug which was reported to Debian in February 2006 and fixed in Debian in June 2006.
Where libnss-ldap is used for pwd and grp lookups, direct exploits of the bad code are at least limited because the library's position as an authentication plugin: the ldap server is trusted for username/uid lookup so is pretty powerful anyway and sending bad data wouldn't help the ldap server very much more. However, system administrators might reasonably wish to rely on nss lookup order to prevent bad data about powerful system users being retrieved from ldap and think that they've prevented exploits mediated by the ldap server - but it would not be wise for them to do so given the code quality and structure.
Absent a compelling reason, I would recommend against inclusion of this package in Ubuntu main.
One possible mitigation strategy would be to recast the code as an nss proxy or cache server, so that extensive LDAP code could be placed in a somewhat-restricted sandbox; it would be queried by the existing nscd query code in the nss system. Such a design would have dealt with some but not all of the past vulnerabilities. Alternatively, it might be possible to rewrite the plugin or such an ldap-querying nscd server in a different implementation language, or to commission a rewrite by very paranoid programmers.
Either of those would be nontrivial programming tasks which would need to be undertaken by developers of a high caliber to be sure of getting the benefits; choosing to expend effort on this would therefore be expensive and carry some risk of failure.
It might be possible to determine which portions of the code we were actually proposing to use and to undertake a detailed line-by-line review; however, such reviews require extensive effort by very experienced programmers.
The ldap code other than for pwd and grp lookups should not be used. There are few compelling scenarios for this functionality. If this functionality is present a system administrator might configure (for example) ldap host lookup, without being aware that this puts their machine's fundamental integrity at significant risk from any rogue data sent by the ldap server.
If due to a compelling reason we include this package in Ubuntu, we should ensure that administrators who choose to enable it are aware of the risks so that they only do so if necessary and are able to consider whether alternative setups might achieve their goals. We should advise those administrators not to rely on nss lookup order or other arrangements which purport to limit ldap lookups only to certain users. Ideally we would disable the lookup kinds which a system administrator might mistakenly think were safe to use with an untrustworthy ldap server. We should also be prepared to issue advisories regarding future vulnerabilities: the code has had security bugs in the past and it is virtually certain that there are security bugs still present.
- - Ian Jackson
Quoting RickClark's comments:
- These packages are ubiquitous. They are shipped with every major distribution and some commercial UNIX products. In fact, Redhat has included this package for at least eight years.
- These packages are required LDAP authentication. LDAP authentication is used in almost all large commercial environments and is extremely popular smaller ones as well.
- This is being used by our users anyway, including many who pay for support contracts. Any bug in these packages will affect us and will be seen as an Ubuntu issue whether we official support them or not.
- The Support Team has requested that we officially support these packages. Customers are demanding it and are running it anyway.
- Upstream is responsive. I have discussed this issue with the upstream author, who admits that rewrite might be necessary. He is more that willing to accept patches and already does so from Redhat and Novell.
- Kees has taken a look at the code, and although he shares Ian's concerns, specifically concerning libpam-ldap, he considers the risk low and is fine with inclusion.
- These packages are extremely well tested and have been used for nearly a decade.
While none of these arguments might be enough on their own, I believe combined they make a strong case that it is a low risk to support these packages, that not doing so is a disservice to a substantial number of our users, and hinders the adoption of Ubuntu in many environments.
Since this is an explicit goal, I approve this.