User passwords logged when LDAP misconfigured

Bug #1009262 reported by Craig Miskell on 2012-06-06
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Son Nguyen

Bug Description

When LDAP is misconfigured, for example pointing to a non-existent LDAP server, the stack trace in the webserver log reports the users password (redacted log snippet to be attached).

It is not a major bug, in that the information is only available to the server administrator under normal circumstances (unless log files are not locked down, which does happen sometimes), but it's still bad form and should be avoided if possible.

Mahara 1.6.0dev 2012051500 (according to lib/version.php). Running on Ubuntu 10.04 and Apache2.

CVE References

Craig Miskell (3-crjig-7) wrote :

Also discussed publicly at - in that thread Nigel seemed to think it wasn't worth the hassle to filter them out, but maybe we should have another look.

Hash: SHA1

On 06/06/12 12:55, Richard Mansfield wrote:
> Also discussed publicly at
> - in that
> thread Nigel seemed to think it wasn't worth the hassle to filter
> them out, but maybe we should have another look.
Good to see it's been noticed before. To add to the discussion, the
particular trouble with the LDAP case is that the password is almost
invariably going to mean something elsewhere than just Mahara (e.g. in
the Catalyst case, a lot of other systems). If it was just the mahara
password, it wouldn't be quite so bad.

Although I suppose an evil administrator could just modify the PHP and
log the passwords elsewhere.

In this specific case, it looks like the password is passed as a
string argument which gets automatically dumped in the stacktrace.
Perhaps a simple solution would be to embed it in an object which gets
passed around, thus hiding it from exposure in stack traces.

- --
Craig Miskell
Systems Administrator, Catalyst IT
DDI: +64 4 8020427
Some of us here are sysadmins, and network admins, and even Windows
admins. Clubbing baby harp seals would a socially acceptable step
*up*. -- butting on ARK
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Changed in mahara:
status: New → Confirmed
importance: Undecided → Medium

That authenticate_user_account function has to stick around for a while, because third party auth plugins rely on it. But it doesn't need to be called on any of the auth methods in core, we could add some new function that takes an object, as Craig suggested, and only call authenticate_user_account for those auth methods that don't implement the new function (or something like that). Might be a good thing to do anyway, because some auth methods don't want to see a password.

Aaron Wells (u-aaronw) wrote :

Adding Taylor Judd to this issue, because he reported the same problem:

Aaron Wells (u-aaronw) wrote :

It appears this issue has been around for a while. As mentioned in earlier comments, it's a tricky one to solve. We need to move the password around in plaintext because eventually it has to be passed as a plaintext string to the PHP core function ldap_bind().

As mentioned above, we could reimplement things so that the password is an object property instead of a string, and that would make it less likely to be printed out in a stack trace. We could even take things a step further and obfuscate the password, scrambling it in some reversible way using a random string as a key.

Son Nguyen (ngson2000) wrote :

Test case:

1. Add LDAP authentication to an institution. Set a wrong Host URL to it.
2. Logout and try to login as an user
3. The user's password must not be shown in the screen or error log

Son Nguyen (ngson2000) wrote :

I think this is the bug inside the LDAP auth lib.

The method ldap_find_userdn() should return false if there is no result from LDAP queries.

Please my patch in the attached file

Son Nguyen (ngson2000) wrote :
Changed in mahara:
status: Confirmed → In Progress
assignee: nobody → Son Nguyen (ngson2000)
Robert Lyon (robertl-9) on 2014-07-31
Changed in mahara:
milestone: none → 1.10.0
status: In Progress → Fix Committed
importance: Medium → High
importance: High → Critical
Robert Lyon (robertl-9) on 2014-08-01
information type: Private Security → Public Security
Aaron Wells (u-aaronw) on 2014-10-21
Changed in mahara:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Bug attachments