Source: awl
Version: 0.53-1
Severity: important
Tags: security upstream
Hi.
I was looking through /usr/share/awl/inc/Session.php in order
to write a patch to add support for Apache's REDIRECT_REMOTE_USER
to the "normal" REMOTE_USER env var and stumbled accross some potential
issues.
1) In _CheckLogin()... there is that case:
else if ( !isset($_COOKIE['sid']) &&
isset($c->authenticate_hook['server_auth_type']) )
with then:
if ( is_array($c->authenticate_hook['server_auth_type']) ) {
...
else if ( $c->authenticate_hook['server_auth_type'] == $_SERVER['AUTH_TYPE']
) {
...
In the second case, i.e. server_auth_type is not an array the following
happens for the login:
list($username) = explode('@', $_SERVER['REMOTE_USER']);
$this->Login($username, "", true); // Password will not be checked.
a) First it's already questionable why the array case is handled differently
because AFAIU,... when server_auth_type is an array that means just
that more auth methods are tried...
b) But more cirtical is the explode... and that everything behind an
"@" is split of from REMOTE_USER.
I guess the idea is to take only the "foo" in usernames of the form
"f...@bar.org".. but this is IMHO a security issue.
Given that Davical can serve many vhosts/domains from one and the same DB.
there might be different users like f...@bar.com and f...@bar.org ...
but now.... these get "mapped" to the same davical username.
Solution... don't to the explode.... or will this have any side effects.
2) Less serious and more abstract... the LSIDLogin()... aka "long term session
cookies"
Yeah well the comments in the code already tell that this is "this is all
horribly insecure".... which makes me shiver and question whether the whole
thing shouldn't be reconsidered...
The LSID is md5_user_no;validation_string... md5_user_no is simply
the MD5sum of the numeric UIDs... so everyone can calculate these very easily.
Even though I don't think that this already means a security problem
(all credentials seem to be in validation_string... it makes me wonder
why is the MD5 made of this?
The LSID doesn't contain an expiry date... well that alone is not a problem
as we more or less tell the users ("forget met not") that this will stay.
What works is: If a user changes the pwd... the LSID won't work anymore..
But small problem:
In case a user tries to login with a LSID cookie and that fails...
then IMHO that cookie should be deleted... even if it's just for clean up.
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
