Warnings when LDAP server is not available
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Fix Released
|
High
|
Unassigned | ||
15.10 |
Fix Released
|
High
|
Unassigned |
Bug Description
Version: master (16.04), 15.10
Platform: any
Browser: any
When logging in using LDAP authentication, I get the following error message if the LDAP server is not available.
and the password for the ldap special user does appear.
(I changed it to 'visiblepassword')
[Mon Jan 25 21:00:44.324225 2016] [:error] [pid 11] [client 172.17.0.1:37746] [WAR] a2 (auth/ldap/
[Mon Jan 25 21:00:44.324262 2016] [:error] [pid 11] [client 172.17.0.1:37746] Call stack (most recent first):, referer: http://
[Mon Jan 25 21:00:44.324272 2016] [:error] [pid 11] [client 172.17.0.1:37746] * log_message(
[Mon Jan 25 21:00:44.324281 2016] [:error] [pid 11] [client 172.17.0.1:37746] * error(2, "ldap_bind(): Unable to bind to server: Can't conta...", "/var/www/
[Mon Jan 25 21:00:44.324288 2016] [:error] [pid 11] [client 172.17.0.1:37746] * ldap_bind(
[Mon Jan 25 21:00:44.324296 2016] [:error] [pid 11] [client 172.17.0.1:37746] * AuthLdap-
[Mon Jan 25 21:00:44.324303 2016] [:error] [pid 11] [client 172.17.0.1:37746] * AuthLdap-
[Mon Jan 25 21:00:44.324310 2016] [:error] [pid 11] [client 172.17.0.1:37746] * login_submit(
[Mon Jan 25 21:00:44.324316 2016] [:error] [pid 11] [client 172.17.0.1:37746] * call_user_
[Mon Jan 25 21:00:44.324323 2016] [:error] [pid 11] [client 172.17.0.1:37746] * Pieform-
[Mon Jan 25 21:00:44.324331 2016] [:error] [pid 11] [client 172.17.0.1:37746] * auth_setup() at /var/www/
[Mon Jan 25 21:00:44.324338 2016] [:error] [pid 11] [client 172.17.0.1:37746] * require(
[Mon Jan 25 21:00:44.324345 2016] [:error] [pid 11] [client 172.17.0.1:37746] , referer: http://
[Mon Jan 25 21:00:44.326490 2016] [:error] [pid 11] [client 172.17.0.1:37746] [WAR] a2 (auth/ldap/
[Mon Jan 25 21:00:44.326518 2016] [:error] [pid 11] [client 172.17.0.1:37746] Call stack (most recent first):, referer: http://
[Mon Jan 25 21:00:44.326544 2016] [:error] [pid 11] [client 172.17.0.1:37746] * log_message("LDAP connection failed: ldaps:/
[Mon Jan 25 21:00:44.326553 2016] [:error] [pid 11] [client 172.17.0.1:37746] * log_warn("LDAP connection failed: ldaps:/
[Mon Jan 25 21:00:44.326562 2016] [:error] [pid 11] [client 172.17.0.1:37746] * AuthLdap-
[Mon Jan 25 21:00:44.326569 2016] [:error] [pid 11] [client 172.17.0.1:37746] * login_submit(
[Mon Jan 25 21:00:44.326576 2016] [:error] [pid 11] [client 172.17.0.1:37746] * call_user_
[Mon Jan 25 21:00:44.326585 2016] [:error] [pid 11] [client 172.17.0.1:37746] * Pieform-
[Mon Jan 25 21:00:44.326593 2016] [:error] [pid 11] [client 172.17.0.1:37746] * auth_setup() at /var/www/
[Mon Jan 25 21:00:44.326600 2016] [:error] [pid 11] [client 172.17.0.1:37746] * require(
[Mon Jan 25 21:00:44.326608 2016] [:error] [pid 11] [client 172.17.0.1:37746] , referer: http://
Changed in mahara: | |
status: | New → Confirmed |
milestone: | none → 16.04.0 |
information type: | Public → Public Security |
no longer affects: | mahara/1.10 |
Changed in mahara: | |
milestone: | 16.04.0 → 16.04.1 |
Changed in mahara: | |
milestone: | 16.04.1 → 16.04.2 |
This bug is similar to Bug 1009262 (User passwords logged when LDAP misconfigured), but in this case it's logging the password that Mahara itself uses to bind to the LDAP server. Specifically, that's field 8 on this manual page: manual. mahara. org/en/ 15.10/administr ation/instituti ons.html# index-17
The actual security implications of this bug are limited by the fact that an attacker needs read-access to the web server error logs. And in most systems, if a user has read access to those logs, they most likely already have read-access to Mahara's "config.php" file and could retrieve the LDAP bind password from the database (as this password has to be stored in plaintext; unlike user passwords, which are hashed).
Additionally, unlike Bug 1009262, in this case the exposed password is not a user password (which is likely used by the same human being for other services), but a password for an automated account. In a properly configured system, this password will be unique to this one account, and the account will be limited to read-only access in the LDAP context where user data and/or group data is stored.
It's worth noting this LDAP configuration field is, in fact, optional. It doesn't need to be filled in for institutions that allow anonymous binds (perhaps using the network to enforce LDAP access security), or for institutions that are not doing user auto-creation or LDAP user sync or LDAP group sync.
It's still worth fixing this issue, however, because of the possibility that the server logs may unexpectedly be made accessible to others, or the possibility of a configuration change printing error messages to the web front-end instead of the logs.