A note about auth_ext in MRBS

MRBS is a room and resource reservation system, implemented as a PHP web application. We use MRBS to manage study rooms in our library.

auth_ext is a user authentication mechanism in MRBS. Basically, auth_ext delegates user authentication to an external program, executed by MRBS in response to a request. I noticed a number of people on the community mailing list who seemed to be using auth_ext to authenticate against Kerberos, Active Directory, and other sources; these messages seemed to suggest that potentially sensitive credentials were being passed to the external program on the command line. This seemed like a bad idea to me, since a local user on a *nix webserver running MRBS could potentially get the credentials of these users by watching the process listing (Cal Poly Pomona, for the record, uses auth_ldap, which is not related to auth_ext and does not pass credentials in a suspect way). If these credentials were also valid for storage, email, or other sensitive resources (as, in my experience, credentials for those sources often are), the impact of such an compromise could be quite serious. I wrote the following message to the community mailing list summarizing my concerns:

As commonly implemented, external authentication modules (at least, those shipped with MRBS -- auth_ldap.pl, auth_ldapsearch.pl, auth_pam.pl, and crypt_passwd.pl -- and some recent examples from this list [1]) can leak plaintext username and password combinations to unprivileged attackers on the machine hosting MRBS. Specifically, an attacker can easily see the usernames and passwords by looking for the name of the authentication script in, e.g., the output of the 'ps' command.

To reproduce the problem in an obvious way (*not* on a production setup), we can write an authentication module called auth_slow.pl:


# authenticate everybody
exit 0;

(Obviously you wouldn't want to use this as an authentication module, but it sleeps for long enough for us to easily see the problem.)

Add the following to config.inc.php, commenting out your existing auth configuration:

$auth['type'] = "ext";
$auth['prog'] = "/path/to/auth_slow.pl";
$auth['params'] = "#USERNAME# #PASSWORD#";

and then try to log in to MRBS. The page will hang while the script sleeps; while it does that, do something like:

ps -ef | grep "auth_slow.pl"

in a shell on your server and you'll see the script invocation with your username and password sitting there. Obviously you shouldn't do this on your production MRBS, and should take care to ensure that no one else is using your MRBS while you do this.

I don't think there's an easy fix for this issue (it's considered bad practice in general to pass secret values directly to a program through the command line because of issues like this), but it should probably be documented so people can evaluate whether external authentication is a good fit for their environment.

Let me know if any of this is unclear.

[1] http://sourceforge.net/mailarchive/message.php?msg_id=27835226


(from the mrbs-general list archives)

Unfortunately, there seemed to be little interest in documenting this behavior. It is a rather obvious consequence of this sort of authentication if you're familiar with how *nix works, but there's no guarantee that everyone who uses MRBS is familiar enough with *nix to make that connection.