Main Inclusion Report for libpam-ldap

Requirements

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/libp/libpam-ldap, available for all supported architectures

2. Rationale:

   • Part of edubuntu-network-auth-server spec, needed for ldap network authentication

3. Security:

   • No CVE entries.

   • No recent entries in Secunia history.

   • libpam-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.
   • libpam-ldap opens a random source port to a destination port that is either listed specifically in the configuration file, or determined from the URI of the destination.
   • Source code review:

4. Quality assurance:

   • Package requires /etc/ldap.conf to be configured in order to function.

   • No showstopper Debian bugs.

   • Good maintenance in Debian.

   • Active upstream.

   • No critical bugs upstream

   • Does not deal with exotic hardware which we cannot support.

5. Standards compliance:

   • Meets the FHS, Debian Policy

   • Meets Debian library packaging guide standards.

   • Standard debhelper/cdbs/dbs packaging, standard patch system.

6. Dependencies:

   • All in Main

Reviewers

IanJackson 14.8.2007

I have reviewed libpam-ldap 184-1. It consists primarily of a single 4kloc C file which implements a pam module in terms of libldap. The code 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 statement in the report above that there are no CVEs is incorrect: some of the CVE entries which show up in a search for nss-ldap are bugs in pam-ldap.

Direct exploits of the bad code are at least limited because the library's position as an authentication plugin: the ldap server is trusted to permit logins so is pretty powerful anyway and sending bad data wouldn't help it much. However, some of the past vulnerabilities involved security-weaking or security-defeating malfunctions even in the presence of nonmalicious ldap servers. Furthermore, system administrators might reasonably wish to rely on pam mechanisms to prevent login as more powerful system users 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 develop (or find) a pam proxy plugin, which could itself be much simpler and might enable the extensive LDAP code to be placed in a somewhat-restricted sandbox. Such a design would have dealt with some but not all of the past vulnerabilities. Alternatively, it might be possible to rewrite the plugin in a different implementation language or to commission a rewrite by very paranoid programmers.

Either of those would be significant programming tasks which would need to be undertaken by developers of a high caliber to be sure of getting any of the benefits; choosing to expend effort on this would therefore be expensive and carry some risk of failure.

It is difficult to see other plausible mitigation strategies. The code is too sprawling for review to be effective.

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 pam facilities which purport to limit ldap logins only to certain users. 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

MartinPitt

Quoting RickClark's comments:

1. 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.
2. These packages are required LDAP authentication. LDAP authentication is used in almost all large commercial environments and is extremely popular smaller ones as well.
3. 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.
4. The Support Team has requested that we officially support these packages. Customers are demanding it and are running it anyway.
5. 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.
6. 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.
7. 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.